Skip to contentSkip to conversation

Fix BUG: using smp_processor_id() in preemptible [00000000] code: nfsd/2852

PATCH Applied Ankita Garg 2 participants 2 messages Apr 18, 2007 Memory management

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Fix BUG: using smp_processor_id() in preemptible [00000000] code: nfsd/2852

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(-)
mm/slab.c +1 -2
Index: linux-2.6.20-rt8/mm/slab.c
===================================================================
@@ -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,

Signature · 4 lines
Ankita Garg ([email protected])
Linux Technology Center
IBM India Systems & Technology Labs, 
Bangalore, India   
Applied
#1 lore raw
Quoted 7 lines · Ankita Garg

While running some tests on 2.6.20-rt8 with DEBUG_PREEMPT on, I hit the following BUG:

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().

thanks, applied!

Ingo