* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> Hello!
> 
> This patch series adds lockdep-based checking to the rcu_dereference() 
> primitive in order to flag misuses of RCU.  The first four patches put the 
> RCU infrastructure in place, the next eight use this infrastructure in the 
> net, sched, vfs, radix-tree, idr, and security subsystems, and patch 13 
> documents how to use the new lockdep-checked rcu_dereference() primitives.  
> The remaining eight patches are other changes that also need to be applied, 
> including some relatively urgent RCU_STALL patches.
> 
> The new (and default-disabled) CONFIG_PROVE_RCU makes this safe to include 
> in tip/core/rcu -- unlike v2 and earlier, your system won't complain about 
> RCU misuse unless you ask it to.  There are still several situations that 
> trigger on systems I have access to (and I have email out on a couple of 
> them), some of the remaining will be triggered only by hardware I don't have 
> access to and kernel features I am unfamiliar with. So this is ready for 
> much wider testing.
> 
> Changes since v5 (http://lkml.org/lkml/2010/2/17/271)

I've applied them to tip:core/rcu, Thanks Paul!

Here's a first bugreport, we've got a cgroups hit in task_subsys_state(), 
during bootup:

==============================================
[ BUG: Unsafe rcu_dereference_check() usage! ]
----------------------------------------------
include/linux/cgroup.h:492 invoked rcu_dereference_check() without protection!

other info that might help us debug this:

1 lock held by swapper/0:
 #0:  (&rq->lock){......}, at: [<ffffffff818b2c20>] init_idle+0x30/0xca

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.33-tip-00720-g4cc116f-dirty #10310
Call Trace:
 [<ffffffff81072248>] lockdep_rcu_dereference+0x8c/0x95
 [<ffffffff8103735c>] task_subsys_state+0x3d/0x55
 [<ffffffff810376f2>] set_task_rq+0x1c/0x4f
 [<ffffffff818b2c73>] init_idle+0x83/0xca
 [<ffffffff835cd42a>] sched_init+0x4d1/0x54b
 [<ffffffff835bac07>] start_kernel+0x1c2/0x42b
 [<ffffffff835ba2bc>] x86_64_start_reservations+0xa7/0xab
 [<ffffffff835ba3b8>] x86_64_start_kernel+0xf8/0x107
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is enabled.
NR_IRQS:4352
Console: colour VGA+ 80x25

Config attached. I havent had the time to look into it yet, just wanted to 
report it to you, but it looks like a false positive - this is so early during 
init that we cannot schedule and the rq lock is held anyway. (in a raw manner)

	Ingo