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

[Josh Triplett]

On Tue, Dec 15, 2009 at 03:02:41PM -0800, Paul E. McKenney wrote:
> From: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/