Re: idr_remove

[Lorenzo Hernández García-Hierro]

El sáb, 19-02-2005 a las 23:32 +1100, Russell Coker escribió:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109838483518162&w=2
> 
> I am getting messages "idr_remove called for id=0 which is not allocated" when 
> SE Linux denies search access to /dev/pts.
> 
> The attached file has some klogd output showing the situation, triggered in 
> this case by installing a new kernel package on a SE Debian system.  The 
> above URL references Jim Houston's message with the patch to add this 
> warning.

The problem seems to be in a call back from idr_remove() to
sub_remove()@/lib/idr.c:284 which leads to calling idr_remove_warning(),
doing the weird stack dump, when some logics don't work as expected.

Jan 17 13:45:43 lyta kernel:  [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel:  [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel:  [idr_remove+35/144] idr_remove+0x23/0x90

The spurious function called by sub_remove() (leads to the
dump_stack+0x17/0x20):

+static void idr_remove_warning(int id)
+{
+	printk("idr_remove called for id=%d which is not allocated.\n", id);
+	dump_stack();
+}
+

The changes that lead to such warning and stack dump

@sub_remove
+	n = id & IDR_MASK;
+	if (likely(p != NULL && test_bit(n, &p->bitmap))){
(...etc...)

idr_remove() is called, among other places, within the Device Mapper
(DM) code that I suppose you are using, right?

I don't have time to make further checking, but seems to be somewhat
type of devices handling and IDR minor numbers allocation tracking
black magic, someone could have a further a look at it?

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@xxxxxxx> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmadadigitalmente