linux-kernel - Re: [PATCH RFC tip/core/rcu 18/18] rcu: add primitives to check for RCU read-side critical sections

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20091216010439.GD2408@feather>
Date:	Tue, 15 Dec 2009 17:04:39 -0800
From:	Josh Triplett <josh@...htriplett.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
	Valdis.Kletnieks@...edu, dhowells@...hat.com
Subject: Re: [PATCH RFC tip/core/rcu 18/18] rcu: add primitives to check
 for RCU read-side critical sections

On Tue, Dec 15, 2009 at 03:02:41PM -0800, Paul E. McKenney wrote:
> From: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> 
> Proposed for 2.6.34, not for inclusion.
> 
> Create rcu_read_lock_held(), rcu_read_lock_bh_held(),
> rcu_read_lock_sched_held(), and srcu_read_lock_held() primitives that
> return non-zero if there might be the corresponding type of RCU read-side
> critical section in effect at the time that they are invoked.  If there is
> doubt, they report being in the critical section.  They give exact
> answers if CONFIG_PROVE_LOCKING.
> 
> Also create rcu_dereference_check(), which takes a second boolean argument
> into which one puts rcu_read_lock_held() or similar.  For example:
> 
> 	rcu_dereference_check(gp, rcu_read_lock_held() ||
> 				  lockdep_is_held(my_lock));

Useful for the case where you do have an additional lock, but it seems
like it would help to have variants for the most common cases;
specifically:
rcu_dereference_check(thing, rcu_read_lock_held())
rcu_dereference_check(thing, rcu_read_lock_bh_held())
and so on.

Even then, it seems painful to have to annotate each rcu_dereference.
Ideally, I'd propose the reverse: annotate any rcu_dereference which
*can* occur outside an RCU read-side critical section.  (Variants of RCU
notwithstanding...)

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/