From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [0/8] netpoll/bridge fixes Date: Thu, 17 Jun 2010 13:18:30 +0300 Message-ID: <20100617101830.GJ7912@redhat.com> References: <1276657139.19249.50.camel@edumazet-laptop> <1276657400.19249.53.camel@edumazet-laptop> <20100616033336.GA17440@gondor.apana.org.au> <20100615.214702.57478137.davem@davemloft.net> <20100616230249.GJ2457@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Miller , herbert@gondor.hengli.com.au, eric.dumazet@gmail.com, shemminger@vyatta.com, frzhang@redhat.com, netdev@vger.kernel.org, amwang@redhat.com, mpm@selenic.com To: "Paul E. McKenney" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39759 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755423Ab0FQKYG (ORCPT ); Thu, 17 Jun 2010 06:24:06 -0400 Content-Disposition: inline In-Reply-To: <20100616230249.GJ2457@linux.vnet.ibm.com> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Jun 16, 2010 at 04:02:49PM -0700, Paul E. McKenney wrote: > On Tue, Jun 15, 2010 at 09:47:02PM -0700, David Miller wrote: > > From: Herbert Xu > > Date: Wed, 16 Jun 2010 13:33:36 +1000 > > > > > On Wed, Jun 16, 2010 at 05:03:20AM +0200, Eric Dumazet wrote: > > >> > > >> 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? > + __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.