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: <20091216020855.GI6783@linux.vnet.ibm.com>
Date:	Tue, 15 Dec 2009 18:08:55 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Josh Triplett <josh@...htriplett.org>
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 05:04:39PM -0800, Josh Triplett wrote:
> 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.

I figured that I would try applying rcu_dereference_check() to a few
places and see what the most common variants really are.  I briefly
considered defining the set, but choked on the possibility of code
that might be executed from within several different variants of RCU,
so decided to start with the single general-purpose variant.

> 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...)

I was completely with you to start with, but...

Peter Zijlstra reminded me that his earlier foray into this space turned
up a number of situations where the code containing rcu_dereference()
simply cannot know which combinations of locks and/or RCU flavors should
be in effect.  One example of this is the RCU-protected trie, which -can-
be RCU-protected on read, but -also- can be used with locks.  And each
caller of course would supply a different lock.

I would not be surprised to find that we end up wanting a shorthand
for rcu_dereference_check(thing, rcu_read_lock_held()), but am less sure
about the others.

							Thanx, Paul

PS. And thank you for looking these over!
--
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/