[PATCH RFC tip/core/rcu 0/18] rcu: simplify race conditions, addchecking

[Paul E. McKenney]

Hello!

This is just a sneak preview of RCU patches that I have in flight, not
yet for inclusion.

Patches 1-10 simplify TREE_RCU's (and TREE_PREEMPT_RCU's) race conditions
by prohibiting grace periods from starting while force_quiescent_state()
is active.  Patch 10 maintains grace-period latency by the simple
expedient of having force_quiescent_state() check to see if someone
wanted to start a grace period, and, if so, starting one on their behalf.

Patch 11 adds parameters to rcutorture to allow testing with extremely
rapid re-invocations of force_quiescent_state() -- microseconds rather
than the previous milliseconds.

Patch 12 makes the RCU and rcutorture entries of the MAINTAINERS file
call out the correct source files, which have changed due to the recent
re-implementation.

Patches 13-18 add debugging checks, so that an rcu_dereference(p)
can now be rcu_dereference(p, rcu_read_lock_held()), which
will complain if invoked outside of an RCU read-side critical
section when CONFIG_PROVE_LOCKING is specified.  There are
also rcu_read_lock_bh_held(), rcu_read_lock_sched_held(), and
srcu_read_lock_held() for the other flavors of RCU.

One can also do something like:

	p = rcu_dereference_check(gp, rcu_read_lock_bh_held() ||
				  lockdep_is_held(my_lock));

to handle the case where either the access must either be protected
by RCU-bh or by my_lock.

Again, strictly FYI, not yet for inclusion.

							Thanx, Paul
--
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/