linux-kernel - Re: [PATCH tip/core/rcu 0/21] v6 add lockdep-based diagnostics to rcu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Feb 2010 11:00:22 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	linux-kernel@...r.kernel.org, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, josh@...htriplett.org,
	dvhltc@...ibm.com, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com
Subject: Re: [PATCH tip/core/rcu 0/21] v6 add lockdep-based diagnostics to
 rcu_dereference()

* Paul E. McKenney <paulmck@...ux.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

View attachment "config" of type "text/plain" (73622 bytes)