Bug 610967 - INFO: suspicious rcu_dereference_check() usage.
INFO: suspicious rcu_dereference_check() usage.
Status: CLOSED DUPLICATE of bug 622149
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-02 17:57 EDT by Jay Fenlason
Modified: 2014-08-31 19:29 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-21 16:03:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


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

  None (edit)
Description Jay Fenlason 2010-07-02 17:57:49 EDT
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 02:58:57 EDT
Is it still happening in 2.6.35-rc5?
Comment 2 Michal Jaegermann 2010-07-14 13:08:57 EDT
(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 06:23:53 EDT
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 11:10:10 EDT
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 17:38:13 EDT
(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 18:15:55 EDT
(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 14:53:45 EDT
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 08:24:34 EDT
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 05:50:10 EDT
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 17:47:43 EDT
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 06:50:49 EDT
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 16:03:34 EDT
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.