Bug 16323

Summary:	2.6.35-rc3-git4 - kernel/sched.c:616 invoked rcu_dereference_check() without protection!
Product:	Platform Specific/Hardware	Reporter:	Maciej Rutecki (maciej.rutecki)
Component:	x86-64	Assignee:	platform_x86_64 (platform_x86_64)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	cebbert, florian, maciej.rutecki, miles.lane, Nicolas.Mailhot, paulmck, rjw
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.35-rc3-git4	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	16055

Description Maciej Rutecki 2010-07-01 18:16:49 UTC

Subject    : 2.6.35-rc3-git4 - kernel/sched.c:616 invoked rcu_dereference_check() without protection!
Submitter  : Miles Lane <miles.lane@gmail.com>
Date       : 2010-07-01 12:21
Message-ID : AANLkTini6hz2LFeZi8CMUmY3xw1MU7NxmyesuxZ4oCdo@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=127798693125541&w=2

This entry is being used for tracking a regression from 2.6.34.  Please don't
close it until the problem is fixed in the mainline.

Comment 1 Rafael J. Wysocki 2010-07-09 21:19:02 UTC

Fixed by by commit dc61b1d6 ("sched: Fix PROVE_RCU vs cpu_cgroup").

Comment 2 Chuck Ebbert 2010-08-09 05:19:36 UTC

This bug is not fixed, but I can't reopen it.


[ 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: [<ffffffff81052b4b>]
cpu_maps_update_begin+0x17/0x19
 #1:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81052a5e>]
cpu_hotplug_begin+0x2c/0x53
 #2:  (&rq->lock){-.....}, at: [<ffffffff814919c9>] init_idle+0x30/0x131

stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35.1-4.rc1.fc14.x86_64 #1
Call Trace:
 [<ffffffff8107bc7a>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff8103fda5>] task_group+0x80/0x8f
 [<ffffffff8103fdcb>] set_task_rq+0x17/0x73
 [<ffffffff81491a83>] init_idle+0xea/0x131
 [<ffffffff81491e53>] fork_idle+0x92/0xa3
 [<ffffffff8107e760>] ? mark_held_locks+0x50/0x72
 [<ffffffff8148f8f9>] do_fork_idle+0x1c/0x2d
 [<ffffffff8148fa41>] do_boot_cpu+0x137/0x9ac
 [<ffffffff8148f8dd>] ? do_fork_idle+0x0/0x2d
 [<ffffffff81490ada>] native_cpu_up+0x100/0x1c2
 [<ffffffff81491f2c>] _cpu_up+0x9d/0xf9
 [<ffffffff8149205b>] cpu_up+0xd3/0xe5
 [<ffffffff81d78d86>] kernel_init+0x105/0x2c9
 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
 [<ffffffff81499210>] ? restore_args+0x0/0x30
 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9
 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10

Comment 3 Chuck Ebbert 2010-08-19 07:14:31 UTC

*** Bug 16546 has been marked as a duplicate of this bug. ***

Comment 4 Florian Mickler 2010-09-08 08:12:38 UTC

Is this still a problem in current mainline kernel?

Comment 5 Miles Lane 2010-09-09 16:47:59 UTC

This is fixed, as far as I can tell.

Comment 6 Florian Mickler 2010-09-09 18:53:24 UTC

Another one bites the dust.