Bug 610967 - INFO: suspicious rcu_dereference_check() usage.
Summary: INFO: suspicious rcu_dereference_check() usage.
Status: CLOSED DUPLICATE of bug 622149
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-02 21:57 UTC by Jay Fenlason
Modified: 2014-08-31 23:29 UTC (History)
15 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-09-21 20:03:34 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 16323 None None None Never

Description Jay Fenlason 2010-07-02 21:57:49 UTC
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.

Comment 1 Chuck Ebbert 2010-07-14 06:58:57 UTC
Is it still happening in 2.6.35-rc5?

Comment 2 Michal Jaegermann 2010-07-14 17:08:57 UTC
(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.

Comment 3 Chuck Ebbert 2010-07-16 10:23:53 UTC
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.

Comment 4 Orion Poplawski 2010-07-19 15:10:10 UTC
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

Comment 5 Michal Jaegermann 2010-07-19 21:38:13 UTC
(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

Comment 6 Michal Jaegermann 2010-07-19 22:15:55 UTC
(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.

Comment 7 Jóhann B. Guðmundsson 2010-07-27 18:53:45 UTC
I get the suspicious rcu_dereference_check() usage one in comment 5 on 35-0.57.rc6.git.fc14.i686

Comment 8 Bug Zapper 2010-07-30 12:24:34 UTC
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

Comment 9 Joachim Frieben 2010-08-16 09:50:10 UTC
For current F14 and kernel 2.6.35.2-8.fc14.x86_64 I do see the backtrace reported in comment #5.

Comment 10 Gene Snider 2010-08-21 21:47:43 UTC
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

Comment 11 Samuel Bit 2010-09-08 10:50:49 UTC
I still see exactly the same as mentioned in comment #4 with current F14, kernel 2.6.35.4-12.fc14

Comment 12 Jeff Raber 2010-09-21 20:03:34 UTC
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 ***


Note You need to log in before you can comment on or make changes to this bug.