Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The following started show up with 2.6.34-... kernels: [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- include/linux/cgroup.h:492 invoked rcu_dereference_check() without protection! other info that might help us debug this: 1 lock held by swapper/0: #0: (&rq->lock){......}, at: [<ffffffff8147b2d7>] init_idle+0x30/0xcf stack backtrace: Pid: 0, comm: swapper Not tainted 2.6.34-0.9.rc0.git13.fc14.x86_64 #1 Call Trace: [<ffffffff8107cf08>] lockdep_rcu_dereference+0x8c/0x95 [<ffffffff8103ec6b>] task_subsys_state+0x3d/0x55 [<ffffffff8103ec9f>] set_task_rq+0x1c/0x87 [<ffffffff8147b32f>] init_idle+0x88/0xcf [<ffffffff81d97201>] sched_init+0x41b/0x46b [<ffffffff81d7eca2>] start_kernel+0x24d/0x44b [<ffffffff81d7e2bc>] x86_64_start_reservations+0xa7/0xab [<ffffffff81d7e3b8>] x86_64_start_kernel+0xf8/0x107 Version-Release number of selected component (if applicable): kernel-2.6.34-0.9.rc0.git13.fc14.x86_64 and earlier How reproducible: on every boot
I'm seeing this too: Memory: 3911444k/5177344k available (4656k kernel code, 1094632k absent, 171268k reserved, 7280k data, 2712k init) SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- include/linux/cgroup.h:492 invoked rcu_dereference_check() without protection! other info that might help us debug this: 1 lock held by swapper/0: #0: (&rq->lock){......}, at: [<ffffffff8147c40d>] init_idle+0x30/0xcf stack backtrace: Pid: 0, comm: swapper Not tainted 2.6.34-0.10.rc1.git0.fc14.x86_64 #1 Call Trace: [<ffffffff8107cf10>] lockdep_rcu_dereference+0x8c/0x95 [<ffffffff8103ec6b>] task_subsys_state+0x3d/0x55 [<ffffffff8103ec9f>] set_task_rq+0x1c/0x87 [<ffffffff8147c465>] init_idle+0x88/0xcf [<ffffffff81d9a31e>] sched_init+0x41b/0x46b [<ffffffff81d81ca2>] start_kernel+0x24d/0x44b [<ffffffff81d812bc>] x86_64_start_reservations+0xa7/0xab [<ffffffff81d813b8>] x86_64_start_kernel+0xf8/0x107 Hierarchical RCU implementation. NR_IRQS:33024 nr_irqs:440 Extended CMOS year: 2000 Console: colour VGA+ 80x25 console [tty0] enabled Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS: 8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 6367 kB per task-struct memory footprint: 2688 bytes
According to http://lkml.org/lkml/2010/3/10/453 <quote> This one is a false positive that is addressed by a set of boot-time fixes that have recently gone into mainline, this series of commits: c598a070..71da8132 </quote> So I guess that this one can be closed (as UPSTREAM?)