On Thu, Jun 17, 2010 at 01:18:30PM +0300, Michael S. Tsirkin wrote:

On Wed, Jun 16, 2010 at 04:02:49PM -0700, Paul E. McKenney wrote:

quoted

On Tue, Jun 15, 2010 at 09:47:02PM -0700, David Miller wrote:

quoted

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 16 Jun 2010 13:33:36 +1000

quoted

On Wed, Jun 16, 2010 at 05:03:20AM +0200, Eric Dumazet wrote:

quoted

I wonder how these patches were tested, Herbert ?

You know, not everyone enables RCU debugging...

Even though I'm as guilty as you, I have to agree with Eric that
especially us core folks should be running with the various lock
debugging options on all the time.

Maybe someone should add the RCU debugging config option to
Documentation/SubmitChecklist :-)

How about the following added to Documentation/RCU/checklist.txt?

The first is in mainline, the second partly there, and the third
is still languishing in my tree.  I did manage to remove a dependency
on other maintainers, so things will hopefully move a bit faster.

							Thanx, Paul

diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 790d1a8..c7c6788 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt

@@ -365,3 +365,26 @@ over a rather long period of time, but improvements are always welcome!
 	and the compiler to freely reorder code into and out of RCU
 	read-side critical sections.  It is the responsibility of the
 	RCU update-side primitives to deal with this.
+
+17.	Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
+	the __rcu sparse checks to validate your RCU code.  These
+	can help find problems as follows:
+
+	CONFIG_PROVE_RCU: check that accesses to RCU-protected data
+		structures are carried out under the proper RCU
+		read-side critical section, while holding the right
+		combination of locks, or whatever other conditions
+		are appropriate.
+
+	CONFIG_DEBUG_OBJECTS_RCU_HEAD: check that you don't pass the
+		same object to call_rcu() (or friends) before an RCU
+		grace period has elapsed since the last time that you
+		passed that same object to call_rcu() (or friends).
+

Cool, will this also work with synchronize etc?

Unfortunately, it will not.  With call_rcu() and friends you can tag
the struct rcu_head and track it.  With synchronize_rcu() and friends,
there is nothing to track.  :-(

							Thanx, Paul

quoted

+	__rcu sparse checks: tag the pointer to the RCU-protected data
+		structure with __rcu, and sparse will warn you if you
+		access that pointer without the services of one of the
+		variants of rcu_dereference().
+
+	These debugging aids can help you find problems that are
+	otherwise extremely difficult to spot.