Description of problem: I found the following in /var/log/messages in a Rawhide guest running on KVM Version-Release number of selected component (if applicable): 2.6.34-0.10.rc1.git0.fc14.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: The whole messages as found in /var/log/messages : Mar 11 14:34:50 localhost kernel: Mar 11 14:34:50 localhost kernel: =================================================== Mar 11 14:34:50 localhost kernel: [ INFO: suspicious rcu_dereference_check() usage. ] Mar 11 14:34:50 localhost kernel: --------------------------------------------------- Mar 11 14:34:50 localhost kernel: include/linux/cgroup.h:492 invoked rcu_dereference_check() without protection! Mar 11 14:34:50 localhost kernel: Mar 11 14:34:50 localhost kernel: other info that might help us debug this: Mar 11 14:34:50 localhost kernel: Mar 11 14:34:50 localhost kernel: 1 lock held by swapper/0: Mar 11 14:34:50 localhost kernel: #0: (&rq->lock){......}, at: [<ffffffff8147c40d>] init_idle+0x30/0xcf Mar 11 14:34:50 localhost kernel: Mar 11 14:34:50 localhost kernel: stack backtrace: Mar 11 14:34:50 localhost kernel: Pid: 0, comm: swapper Not tainted 2.6.34-0.10.rc1.git0.fc14.x86_64 #1 Mar 11 14:34:50 localhost kernel: Call Trace: Mar 11 14:34:50 localhost kernel: [<ffffffff8107cf10>] lockdep_rcu_dereference+0x8c/0x95 Mar 11 14:34:50 localhost kernel: [<ffffffff8103ec6b>] task_subsys_state+0x3d/0x55 Mar 11 14:34:50 localhost kernel: [<ffffffff8103ec9f>] set_task_rq+0x1c/0x87 Mar 11 14:34:50 localhost kernel: [<ffffffff8147c465>] init_idle+0x88/0xcf Mar 11 14:34:50 localhost kernel: [<ffffffff81d9a31e>] sched_init+0x41b/0x46b Mar 11 14:34:50 localhost kernel: [<ffffffff81d81ca2>] start_kernel+0x24d/0x44b Mar 11 14:34:50 localhost kernel: [<ffffffff81d812bc>] x86_64_start_reservations+0xa7/0xab Mar 11 14:34:50 localhost kernel: [<ffffffff81d813b8>] x86_64_start_kernel+0xf8/0x107 Mar 11 14:34:50 localhost kernel: Hierarchical RCU implementation. Mar 11 14:34:50 localhost kernel: NR_IRQS:33024 nr_irqs:536
I'm seeing something similar: ACPI: Core revision 20100121 ftrace: converting mcount calls to 0f 1f 44 00 00 ftrace: allocating 20730 entries in 82 pages =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 no locks held by swapper/0. stack backtrace: Pid: 0, comm: swapper Not tainted 2.6.34-0.19.rc2.git4.fc14.x86_64 #1 Call Trace: [<ffffffff8107c5a6>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff8103e876>] task_subsys_state+0x46/0x5e [<ffffffff8103e8aa>] set_task_rq+0x1c/0x87 [<ffffffff81048048>] set_task_cpu+0xbf/0xd0 [<ffffffff8104862a>] sched_fork+0xa7/0x116 [<ffffffff8104e7ca>] copy_process+0x6bb/0x1250 [<ffffffff8104f4d9>] do_fork+0x17a/0x395 [<ffffffff81010491>] ? native_sched_clock+0x2d/0x5f [<ffffffff8147cca4>] ? mutex_unlock+0xe/0x10 [<ffffffff81070bfe>] ? sched_clock_cpu+0xc3/0xce [<ffffffff8107b0ef>] ? trace_hardirqs_off+0xd/0xf [<ffffffff81070c4c>] ? cpu_clock+0x43/0x5e [<ffffffff81011160>] kernel_thread+0x75/0x77 [<ffffffff81d81584>] ? kernel_init+0x0/0x2a3 [<ffffffff8100aaa0>] ? kernel_thread_helper+0x0/0x10 [<ffffffff81068f00>] ? rcu_scheduler_starting+0x34/0x58 [<ffffffff814655e2>] rest_init+0x26/0xca [<ffffffff81d81e95>] start_kernel+0x440/0x44b [<ffffffff81d812bc>] x86_64_start_reservations+0xa7/0xab [<ffffffff81d813b8>] x86_64_start_kernel+0xf8/0x107 DMAR: Host address width 36 DMAR: DRHD base: 0x000000feb03000 flags: 0x0
I'm seeing this too with the latest Rawhide fc14: kernel: =================================================== kernel: [ INFO: suspicious rcu_dereference_check() usage. ] kernel: --------------------------------------------------- kernel: include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection! kernel: kernel: other info that might help us debug this: kernel: kernel: kernel: rcu_scheduler_active = 1, debug_locks = 0 kernel: no locks held by swapper/0. kernel: kernel: stack backtrace: kernel: Pid: 0, comm: swapper Not tainted 2.6.34-0.19.rc2.git4.fc14.i686.PAE #1 kernel: Call Trace: kernel: [<c07c9617>] ? printk+0x14/0x1d kernel: [<c0468a54>] lockdep_rcu_dereference+0x7d/0x86 kernel: [<c0432edd>] task_subsys_state+0x41/0x51 kernel: [<c0432f05>] set_task_rq+0x18/0x70 kernel: [<c043c23c>] set_task_cpu+0xa8/0xb6 kernel: [<c043c71e>] sched_fork+0x90/0xf1 kernel: [<c04406b9>] copy_process+0x5a1/0xec2 kernel: [<c040d1b5>] ? sched_clock+0x9/0xd kernel: [<c0441111>] do_fork+0x137/0x2ec kernel: [<c0468e00>] ? mark_lock+0x1e/0x1e1 kernel: [<c0469006>] ? mark_held_locks+0x43/0x5b kernel: [<c0467e19>] ? trace_hardirqs_off+0xb/0xd kernel: [<c045dbde>] ? cpu_clock+0x3b/0x53 kernel: [<c07ca502>] ? mutex_unlock+0xd/0xf kernel: [<c0a57254>] ? kernel_init+0x0/0x21d kernel: [<c040e295>] kernel_thread+0x7e/0x86 kernel: [<c0a57254>] ? kernel_init+0x0/0x21d kernel: [<c0408f3c>] ? kernel_thread_helper+0x0/0x10 kernel: [<c07b639f>] rest_init+0x1f/0xa1 kernel: [<c0a579b2>] start_kernel+0x37d/0x382 kernel: [<c0a570c2>] i386_start_kernel+0xb1/0xb8 Bug #571609 got closed as UPSTREAM because of this: http://lkml.org/lkml/2010/3/10/453
(In reply to comment #1) > I'm seeing something similar: Is it still happening in 2.6.34-rc3-git3?
Well, still happening with 2.6.34-0.28.rc3.git3.fc14.x86_64: ftrace: converting mcount calls to 0f 1f 44 00 00 ftrace: allocating 20748 entries in 82 pages =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 no locks held by swapper/0. stack backtrace: Pid: 0, comm: swapper Not tainted 2.6.34-0.28.rc3.git3.fc14.x86_64 #1 Call Trace: [<ffffffff8107bb06>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff8103e9d7>] task_subsys_state+0x46/0x5e [<ffffffff8103ea0b>] set_task_rq+0x1c/0x87 [<ffffffff81049975>] set_task_cpu+0xa1/0xb2 [<ffffffff81049f55>] sched_fork+0xa7/0x116 [<ffffffff8104e966>] copy_process+0x6bb/0x1250 [<ffffffff81078bf5>] ? tick_nohz_stop_sched_tick+0x360/0x3a9 [<ffffffff8104f675>] do_fork+0x17a/0x395 [<ffffffff81010491>] ? native_sched_clock+0x2d/0x5f [<ffffffff8147d58c>] ? mutex_unlock+0xe/0x10 [<ffffffff81070146>] ? sched_clock_cpu+0xc3/0xce [<ffffffff8107a64f>] ? trace_hardirqs_off+0xd/0xf [<ffffffff81070194>] ? cpu_clock+0x43/0x5e [<ffffffff81011160>] kernel_thread+0x75/0x77 [<ffffffff81d81590>] ? kernel_init+0x0/0x2a3 [<ffffffff8100aaa0>] ? kernel_thread_helper+0x0/0x10 [<ffffffff81068448>] ? rcu_scheduler_starting+0x34/0x58 [<ffffffff81465ec2>] rest_init+0x26/0xca [<ffffffff81d81ea1>] start_kernel+0x440/0x44b [<ffffffff81d812c8>] x86_64_start_reservations+0xb3/0xb7 [<ffffffff81d813c4>] x86_64_start_kernel+0xf8/0x107 DMAR: Host address width 36 DMAR: DRHD base: 0x000000feb03000 flags: 0x0 IOMMU feb03000: ver 1:0 cap c9008020e30260 ecap 1000 DMAR: DRHD base: 0x000000feb01000 flags: 0x0 IOMMU feb01000: ver 1:0 cap c0000020630260 ecap 1000 DMAR: DRHD base: 0x000000feb00000 flags: 0x0 IOMMU feb00000: ver 1:0 cap c0000020630270 ecap 1000 DMAR: DRHD base: 0x000000feb02000 flags: 0x1 IOMMU feb02000: ver 1:0 cap c9008020630260 ecap 1000
I have version 2.6.34-0.28.rc3.git3.fc14.x86_64 (not tainted) and I am seeing the same stack trace as in comment #c1 from Tom London early in the boot process.
kernel-2.6.34-18.fc14.x86_64 Almost near the end of dmesg, not quite tail. full dmesg: http://www.frankly3d.com/dmesg =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- include/net/inet_timewait_sock.h:227 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/0: #0: (net/ipv4/tcp_minisocks.c:41){+.-...}, at: [<ffffffff8105cfa3>] run_timer_softirq+0x193/0x2ef stack backtrace: Pid: 0, comm: swapper Not tainted 2.6.34-18.fc14.x86_64 #1 Call Trace: <IRQ> [<ffffffff8107bfa2>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff8140fac1>] twsk_net+0x44/0x4c [<ffffffff8141005f>] __inet_twsk_kill+0x7e/0xd5 [<ffffffff81410479>] inet_twdr_do_twkill_work+0x5e/0xbf [<ffffffff814105c7>] inet_twdr_hangman+0x35/0x9a [<ffffffff8105d035>] run_timer_softirq+0x225/0x2ef [<ffffffff8105cfa3>] ? run_timer_softirq+0x193/0x2ef [<ffffffff81010385>] ? sched_clock+0x9/0xd [<ffffffff810706f9>] ? sched_clock_local+0x1c/0x82 [<ffffffff81410592>] ? inet_twdr_hangman+0x0/0x9a [<ffffffff81056a76>] ? __do_softirq+0x76/0x1d7 [<ffffffff81056afd>] __do_softirq+0xfd/0x1d7 [<ffffffff81078845>] ? tick_program_event+0x2a/0x2c [<ffffffff8100abdc>] call_softirq+0x1c/0x30 [<ffffffff8100c3df>] do_softirq+0x4b/0xa3 [<ffffffff810566e4>] irq_exit+0x4a/0x8c [<ffffffff81489430>] smp_apic_timer_interrupt+0x8d/0x9b [<ffffffff8100a693>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff8101196d>] ? mwait_idle+0x82/0x94 [<ffffffff81011964>] ? mwait_idle+0x79/0x94 [<ffffffff81008c04>] cpu_idle+0xaf/0xe9 [<ffffffff8146a58f>] rest_init+0xc3/0xca [<ffffffff8146a4cc>] ? rest_init+0x0/0xca [<ffffffff81d82ea1>] start_kernel+0x440/0x44b [<ffffffff81d822c8>] x86_64_start_reservations+0xb3/0xb7 [<ffffffff81d823c4>] x86_64_start_kernel+0xf8/0x107
*** Bug 593026 has been marked as a duplicate of this bug. ***
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
This problem persists in the recent 2.6.35.4-12.fc14.i686 kernel release.
I am seeing this in 2.6.35.4-28.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: [<ffffffff813e9010>] register_pernet_subsys+0x1f/0x47 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.35.4-28.fc14.x86_64 #1 Call Trace: [<ffffffff8107bd3a>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff813e04b9>] sock_update_classid+0x7c/0xa2 [<ffffffff813e054a>] sk_alloc+0x6b/0x77 [<ffffffff8140b281>] __netlink_create+0x37/0xab [<ffffffff813f941c>] ? rtnetlink_rcv+0x0/0x2d [<ffffffff8140cee1>] netlink_kernel_create+0x74/0x19d [<ffffffff8149c3ca>] ? __mutex_lock_common+0x339/0x35b [<ffffffff813f7e9c>] rtnetlink_net_init+0x2e/0x48 [<ffffffff813e8d7a>] ops_init+0xe9/0xff [<ffffffff813e8f0d>] register_pernet_operations+0xab/0x130 [<ffffffff813e901f>] register_pernet_subsys+0x2e/0x47 [<ffffffff81db7bca>] rtnetlink_init+0x53/0x102 [<ffffffff81db835c>] netlink_proto_init+0x126/0x143 [<ffffffff81db8236>] ? netlink_proto_init+0x0/0x143 [<ffffffff810021b8>] do_one_initcall+0x72/0x186 [<ffffffff81d78ebc>] kernel_init+0x23b/0x2c9 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10 [<ffffffff8149e2d0>] ? restore_args+0x0/0x30 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10
(In reply to comment #6) > kernel-2.6.34-18.fc14.x86_64 > Almost near the end of dmesg, not quite tail. > full dmesg: http://www.frankly3d.com/dmesg That link is dead now. Please attach files to the bug instead of posting links. to avoid this issue. > > > > =================================================== > [ INFO: suspicious rcu_dereference_check() usage. ] > --------------------------------------------------- > include/net/inet_timewait_sock.h:227 invoked rcu_dereference_check() without > protection! > This looks like a different bug as it was occurring in inet_timewait_sock.h. A patch was applied to address that issue[1]. If you are still seeing this bug with the latest kernel, please open a new bug. 1: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7ec75c582e639d956ce3afd499f67febe6f902a4;hp=d4c4f07df16c767b8efbc44e7cdf795fac326b33
(In reply to comment #11) > (In reply to comment #6) > > kernel-2.6.34-18.fc14.x86_64 > > Almost near the end of dmesg, not quite tail. > > full dmesg: http://www.frankly3d.com/dmesg > > That link is dead now. Please attach files to the bug instead of posting > links. to avoid this issue. > That was "three months" ago, and no I wasn't going to attach a then4mb dmesg. Live with it.
I'm seeing the same trace as in comment #10 with the same kernel. Intel Core Duo here. Smolt profile is here: http://www.smolts.org/client/show/pub_686b5402-08df-481f-9a15-e5644461cd5a
Created attachment 450838 [details] full dmesg output after boot Seeing the message with 2.5.35.4-28 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: [<ffffffff813e9010>] register_pernet_subsys+0x1f/0x47 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.35.4-28.fc14.x86_64 #1 Call Trace: [<ffffffff8107bd3a>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff813e04b9>] sock_update_classid+0x7c/0xa2 [<ffffffff813e054a>] sk_alloc+0x6b/0x77 [<ffffffff8140b281>] __netlink_create+0x37/0xab [<ffffffff813f941c>] ? rtnetlink_rcv+0x0/0x2d [<ffffffff8140cee1>] netlink_kernel_create+0x74/0x19d [<ffffffff8149c3ca>] ? __mutex_lock_common+0x339/0x35b [<ffffffff813f7e9c>] rtnetlink_net_init+0x2e/0x48 [<ffffffff813e8d7a>] ops_init+0xe9/0xff [<ffffffff813e8f0d>] register_pernet_operations+0xab/0x130 [<ffffffff813e901f>] register_pernet_subsys+0x2e/0x47 [<ffffffff81db7bca>] rtnetlink_init+0x53/0x102 [<ffffffff81db835c>] netlink_proto_init+0x126/0x143 [<ffffffff81db8236>] ? netlink_proto_init+0x0/0x143 [<ffffffff810021b8>] do_one_initcall+0x72/0x186 [<ffffffff81d78ebc>] kernel_init+0x23b/0x2c9 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10 [<ffffffff8149e2d0>] ? restore_args+0x0/0x30 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10 Smolt profile: http://www.smolts.org/client/show/pub_05b82a07-536c-4a95-a715-edd8b0e2acc3
[ 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: [<ffffffff813e9010>] register_pernet_subsys+0x1f/0x47 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.35.4-28.fc14.x86_64 #1 Call Trace: [<ffffffff8107bd3a>] lockdep_rcu_dereference+0xaa/0xb3 [<ffffffff813e04b9>] sock_update_classid+0x7c/0xa2 [<ffffffff813e054a>] sk_alloc+0x6b/0x77 [<ffffffff8140b281>] __netlink_create+0x37/0xab [<ffffffff813f941c>] ? rtnetlink_rcv+0x0/0x2d [<ffffffff8140cee1>] netlink_kernel_create+0x74/0x19d [<ffffffff8149c3ca>] ? __mutex_lock_common+0x339/0x35b [<ffffffff813f7e9c>] rtnetlink_net_init+0x2e/0x48 [<ffffffff813e8d7a>] ops_init+0xe9/0xff [<ffffffff813e8f0d>] register_pernet_operations+0xab/0x130 [<ffffffff813e901f>] register_pernet_subsys+0x2e/0x47 [<ffffffff81db7bca>] rtnetlink_init+0x53/0x102 [<ffffffff81db835c>] netlink_proto_init+0x126/0x143 [<ffffffff81db8236>] ? netlink_proto_init+0x0/0x143 [<ffffffff810021b8>] do_one_initcall+0x72/0x186 [<ffffffff81d78ebc>] kernel_init+0x23b/0x2c9 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10 [<ffffffff8149e2d0>] ? restore_args+0x0/0x30 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10 TOM: 00000000c0000000 aka 3072M Fam 10h mmconf [f7000000, f7ffffff] ACPI: bus type pci registered
Not seeing these messages anymore on my machine with 2.6.35.6-39.fc14.x86_64.
If anyone is seeing these messages on the latest f14 kernel, please attach the output.
Should be fixed in the current updates. If not, f14 is unlikely to see changes beyond security fixes unless they are identified easily backported fixes at this point in its lifecycle.