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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
