Hi, While running some tests on 2.6.20-rt8 with DEBUG_PREEMPT on, I hit the following BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: nfsd/2852 caller is drain_array+0x25/0x132 Call Trace: [<ffffffff8026d828>] dump_trace+0xbd/0x3d8 [<ffffffff8026db87>] show_trace+0x44/0x6d [<ffffffff8026ddc8>] dump_stack+0x13/0x15 [<ffffffff80355e2e>] debug_smp_processor_id+0xe3/0xf1 [<ffffffff802e01b5>] drain_array+0x25/0x132 [<ffffffff802e07ac>] __cache_shrink+0xd5/0x1a6 [<ffffffff802e0a47>] kmem_cache_destroy+0x6c/0xe3 [<ffffffff8846c809>] :nfsd:nfsd4_free_slab+0x16/0x21 [<ffffffff8846c824>] :nfsd:nfsd4_free_slabs+0x10/0x36 [<ffffffff8846daf9>] :nfsd:nfs4_state_shutdown+0x1a2/0x1ae [<ffffffff884570f8>] :nfsd:nfsd_last_thread+0x47/0x76 [<ffffffff8839463a>] :sunrpc:svc_destroy+0x8d/0xd1 [<ffffffff88394738>] :sunrpc:svc_exit_thread+0xba/0xc6 [<ffffffff8845795f>] :nfsd:nfsd+0x2a3/0x2b8 [<ffffffff802600f8>] child_rip+0xa/0x12 --------------------------- | preempt count: 00000001 ] | 1-level deep critical section nesting: ---------------------------------------- .. [<ffffffff80355ddb>] .... debug_smp_processor_id+0x90/0xf1 .....[<ffffffff802e01b5>] .. ( <= drain_array+0x25/0x132) This patch fixes the above issue which arises due to the call to smp_processor_id in drain_array() from mm/slab.c. smp_processor_id() invocation is redundant here, as the call to slab_spin_lock_irq() already fills the value of this_cpu using raw_smp_processor_id(). o Patch to fix BUG in drain_array() Signed-off-by: Ankita Garg <ankita2in.ibm.com> -- slab.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux-2.6.20-rt8/mm/slab.c =================================================================== --- linux-2.6.20-rt8.orig/mm/slab.c 2007-04-18 18:41:22.000000000 +0530 +++ linux-2.6.20-rt8/mm/slab.c 2007-04-18 18:42:21.000000000 +0530 @@ -4121,8 +4121,7 @@ int drain_array(struct kmem_cache *cachep, struct kmem_list3 *l3, struct array_cache *ac, int force, int node) { - int this_cpu = smp_processor_id(); - int tofree; + int tofree, this_cpu; if (!ac || !ac->avail) return 0; Regards, -- Ankita Garg ([EMAIL PROTECTED]) Linux Technology Center IBM India Systems & Technology Labs, Bangalore, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/