DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        b=A+Ow54LHcH/mdXXwZAe9Os3WsUUcCEzAEVpO/BxM37V2JYXa2RWMH37s8RBriI3+mC
         ir/48ueoMqobDOt5JLD+o1f6q5VJQ0XinG62+nAz26K/7WtEvNPjq8QXcgfAQHF2SJUH
         5IsQsCSMTm/MItcFfftZP2XlMJH+12xCOdIpk=
Date: Thu, 9 Jun 2011 01:28:35 +0200
From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, laijs@cn.fujitsu.com,
        dipankar@in.ibm.com, akpm@linux-foundation.org,
        mathieu.desnoyers@polymtl.ca, josh@joshtriplett.org, niv@us.ibm.com,
        tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org,
        Valdis.Kletnieks@vt.edu, dhowells@redhat.com, eric.dumazet@gmail.com,
        darren@dvhart.com, patches@linaro.org
Subject: Re: [PATCH tip/core/rcu 04/28] rcu: Restore checks for blocking in
 RCU read-side critical sections
Message-ID: <20110608232833.GD25771@somewhere.redhat.com>
References: <20110608192943.GA13211@linux.vnet.ibm.com>
 <1307561407-13809-4-git-send-email-paulmck@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1307561407-13809-4-git-send-email-paulmck@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1904
Lines: 36

On Wed, Jun 08, 2011 at 12:29:43PM -0700, Paul E. McKenney wrote:
> Long ago, using TREE_RCU with PREEMPT would result in "scheduling
> while atomic" diagnostics if you blocked in an RCU read-side critical
> section.  However, PREEMPT now implies TREE_PREEMPT_RCU, which defeats
> this diagnostic.  This commit therefore adds a replacement diagnostic
> based on PROVE_RCU.
> 
> Because rcu_lockdep_assert() and lockdep_rcu_dereference() are now being
> used for things that have nothing to do with rcu_dereference(), rename
> lockdep_rcu_dereference() to lockdep_rcu_suspicious() and add a third
> argument that is a string indicating what is suspicious.  This third
> argument is passed in from a new third argument to rcu_lockdep_assert().
> Update all calls to rcu_lockdep_assert() to add an informative third
> argument.
> 
> Finally, add a pair of rcu_lockdep_assert() calls from within
> rcu_note_context_switch(), one complaining if a context switch occurs
> in an RCU-bh read-side critical section and another complaining if a
> context switch occurs in an RCU-sched read-side critical section.
> These are present only if the PROVE_RCU kernel parameter is enabled.
> 
> Again, you must enable PROVE_RCU to see these new diagnostics.  But you
> are enabling PROVE_RCU to check out new RCU uses in any case, aren't you?
> 
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

So, do you think we can get rid of this patch now that we are going to have CONFIG_ATOMIC_SLEEP
working everywhere?

The last remaining piece we need is to check rcu_preempt_depth() from schedule_debug(),
which does a kind of lightweight might_sleep() check alike.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/