Messages in this thread | | | Date | Tue, 15 Dec 2009 15:02:13 -0800 | From | "Paul E. McKenney" <> | Subject | [PATCH RFC tip/core/rcu 0/18] rcu: simplify race conditions, add checking |
| |
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
| |