Description of problem: While looking through my dmesg output, I noticed this on boot: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/sched.c:616 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 3 locks held by swapper/1: #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff81052926>] cpu_maps_update_begin+0x17/0x19 #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8105296b>] cpu_hotplug_begin+0x2c/0x53 #2: (&rq->lock){-.....}, at: [<ffffffff814937ac>] init_idle+0x30/0x136 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.35-0.19.rc3.git4.fc14.x86_64 #1 Call Trace: [<ffffffff8107baf6>] lockdep_rcu_dereference+0xaa/0xb2 [<ffffffff81040067>] task_group+0x80/0x8f [<ffffffff814937ac>] ? init_idle+0x30/0x136 [<ffffffff8104008d>] set_task_rq+0x17/0x73 [<ffffffff8149386b>] init_idle+0xef/0x136 [<ffffffff81493c88>] fork_idle+0xbd/0xce [<ffffffff8107c1bf>] ? mark_held_locks+0x52/0x70 [<ffffffff8149226d>] do_fork_idle+0x1c/0x2d [<ffffffff81491686>] do_boot_cpu+0x145/0xa3b [<ffffffff811127c8>] ? alloc_page_interleave+0x79/0x86 [<ffffffff81492251>] ? do_fork_idle+0x0/0x2d [<ffffffff81492077>] native_cpu_up+0xfb/0x1ce [<ffffffff81493d69>] _cpu_up+0xa0/0x115 [<ffffffff81493eb4>] cpu_up+0xd6/0xe8 [<ffffffff81d78689>] kernel_init+0xf9/0x2bd [<ffffffff8100aaa4>] kernel_thread_helper+0x4/0x10 [<ffffffff8149b3d0>] ? restore_args+0x0/0x30 [<ffffffff81d78590>] ? kernel_init+0x0/0x2bd [<ffffffff8100aaa0>] ? kernel_thread_helper+0x0/0x10 Booting Node 0, Processors #1lockdep: fixing up alternatives. Version-Release number of selected component (if applicable): 2.6.35-0.19.rc3.git4.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1.boot machine 2.look at dmesg 3. Actual results: as above Expected results: no scary messages in dmesg. Additional info: Kernel appears to work fine, so may be a false positive.
Is it still happening in 2.6.35-rc5?
(In reply to comment #1) > Is it still happening in 2.6.35-rc5? Hard to say as at this moment the latest rawhide kernel in koji is 2.6.35-0.36.rc4.git5.fc14. It is surely present there. See also bug 572520 and bug 593026.
Supposedly fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=dc61b1d6 which is in 2.6.35-rc4.
Is this a dupe of bug 572520? I'm seeing with 2.6.35-0.41.rc5.git1.fc14.x86_64 [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/sched.c:616 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 3 locks held by swapper/1: #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff81052b57>] cpu_maps_update_begin+0x17/0x19 #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81052a6a>] cpu_hotplug_begin+0x2c/0x53 #2: (&rq->lock){-.....}, at: [<ffffffff81491594>] init_idle+0x30/0x131 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.35-0.41.rc5.git1.fc14.x86_64 #1 Call Trace: [<ffffffff8107bc42>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff8103fceb>] task_group+0x80/0x8f [<ffffffff8103fd11>] set_task_rq+0x17/0x73 [<ffffffff8149164e>] init_idle+0xea/0x131 [<ffffffff81491a1e>] fork_idle+0x92/0xa3 [<ffffffff8107e728>] ? mark_held_locks+0x50/0x72 [<ffffffff8148f4c4>] do_fork_idle+0x1c/0x2d [<ffffffff8148f60c>] do_boot_cpu+0x137/0x9ac [<ffffffff8148f4a8>] ? do_fork_idle+0x0/0x2d [<ffffffff814906a5>] native_cpu_up+0x100/0x1c2 [<ffffffff81491af7>] _cpu_up+0x9d/0xf9 [<ffffffff81491c26>] cpu_up+0xd3/0xe5 [<ffffffff81d78d86>] kernel_init+0x105/0x2c9 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10 [<ffffffff81498dd0>] ? restore_args+0x0/0x30 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10
(In reply to comment #3) > Supposedly fixed by: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=dc61b1d6 > > which is in 2.6.35-rc4. I am afraid that it does not seem to work. This is from 2.6.35-0.41.rc5.git1.fc14.x86_64: [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by swapper/1: #0: (net_mutex){+.+.+.}, at: [<ffffffff813e3d4c>] register_pernet_subsys+0x1f/0x47 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.35-0.41.rc5.git1.fc14.x86_64 #1 Call Trace: [<ffffffff8107bc42>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff813db209>] sock_update_classid+0x7c/0xa2 [<ffffffff813db29a>] sk_alloc+0x6b/0x77 [<ffffffff81405f59>] __netlink_create+0x37/0xab [<ffffffff813f4108>] ? rtnetlink_rcv+0x0/0x2d [<ffffffff81407bd7>] netlink_kernel_create+0x74/0x19d [<ffffffff81496f02>] ? __mutex_lock_common+0x339/0x35b [<ffffffff813f2b88>] rtnetlink_net_init+0x2e/0x48 [<ffffffff813e3ab6>] ops_init+0xe9/0xff [<ffffffff813e3c49>] register_pernet_operations+0xab/0x130 [<ffffffff813e3d5b>] register_pernet_subsys+0x2e/0x47 [<ffffffff81db7a72>] rtnetlink_init+0x53/0x102 [<ffffffff81db8204>] netlink_proto_init+0x126/0x143 [<ffffffff81db80de>] ? netlink_proto_init+0x0/0x143 [<ffffffff810021b8>] do_one_initcall+0x72/0x186 [<ffffffff81d78ebc>] kernel_init+0x23b/0x2c9 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10 [<ffffffff81498dd0>] ? restore_args+0x0/0x30 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10
(In reply to comment #5) > I am afraid that it does not seem to work. And an update to 2.6.35-0.47.rc5.git2.fc14.x86_64 does not change anything. OTOH maybe this is a different bug although it manifests itself in a similar manner as this seems to come from register_pernet_subsys+0x1f/0x47.
I get the suspicious rcu_dereference_check() usage one in comment 5 on 35-0.57.rc6.git.fc14.i686
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
For current F14 and kernel 2.6.35.2-8.fc14.x86_64 I do see the backtrace reported in comment #5.
I see it for kernel 2.6.35.2-9.fc14.x86_64, as well. It's in /var/log/messages at every boot. Gene
I still see exactly the same as mentioned in comment #4 with current F14, kernel 2.6.35.4-12.fc14
Duping to bug 622149 as it is the same issue and blocks F14Target. Those seeing the 'include/linux/cgroup.h' version of this bug, please look at bug 572520 *** This bug has been marked as a duplicate of bug 622149 ***