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 <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
