From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Milton Miller <miltonm@bga.com>, Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [1/4] rcu: Detect uses of rcu read side in extended quiescent states
Date: Tue, 7 Jun 2011 02:19:07 +0200 [thread overview]
Message-ID: <20110607001905.GE17026@somewhere.redhat.com> (raw)
In-Reply-To: <20110606181021.GL3066@linux.vnet.ibm.com>
On Mon, Jun 06, 2011 at 11:10:21AM -0700, Paul E. McKenney wrote:
> commit c15d76f26712bd5228aa0c6af7a7e7c492a812c9
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date: Tue May 24 08:31:09 2011 -0700
>
> rcu: Restore checks for blocking in RCU read-side critical sections
>
> 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>
A little comment about this patch:
<snip>
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index 88547c8..8b4b3da 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -153,6 +153,12 @@ void rcu_bh_qs(int cpu)
> */
> void rcu_note_context_switch(int cpu)
> {
> + rcu_lockdep_assert(!lock_is_held(&rcu_bh_lock_map),
> + "Illegal context switch in RCU-bh"
> + " read-side critical section");
> + rcu_lockdep_assert(!lock_is_held(&rcu_sched_lock_map),
> + "Illegal context switch in RCU-sched"
> + " read-side critical section");
This looks like more a check to make inside might_sleep().
It's better because might_sleep() triggers the check even if
we don't actually go to sleep.
In fact I believe might_sleep() already does the job fine:
If !PREEMPT, might_sleep() detects that preemption is disabled
by rcu_read_lock().
If PREEMPT, might_sleep() checks rcu_preempt_depth().
next prev parent reply other threads:[~2011-06-07 0:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 3:10 [PATCH 0/4] rcu: Detect rcu uses under extended quiescent state, and fix some Frederic Weisbecker
2011-06-06 3:10 ` Frederic Weisbecker
2011-06-06 3:10 ` [PATCH 1/4] rcu: Detect uses of rcu read side in extended quiescent states Frederic Weisbecker
2011-06-06 3:44 ` [1/4] " Milton Miller
2011-06-06 18:10 ` Paul E. McKenney
2011-06-06 18:20 ` Frederic Weisbecker
2011-06-06 18:37 ` Paul E. McKenney
2011-06-07 0:19 ` Frederic Weisbecker [this message]
2011-06-07 0:42 ` Paul E. McKenney
2011-06-07 1:36 ` Frederic Weisbecker
2011-06-07 4:40 ` Paul E. McKenney
2011-06-07 12:58 ` Frederic Weisbecker
2011-06-07 18:34 ` Paul E. McKenney
2011-06-07 18:49 ` Frederic Weisbecker
2011-06-07 19:22 ` Paul E. McKenney
2011-06-10 8:58 ` Michel Lespinasse
2011-06-06 3:10 ` [PATCH 2/4] nohz: Split extended quiescent state handling from nohz switch Frederic Weisbecker
2011-06-06 3:20 ` [PATCH 2/4 v2] " Frederic Weisbecker
2011-06-06 3:20 ` [PATCH 2/4] " Frederic Weisbecker
2011-06-08 1:15 ` Guan Xuetao
2011-06-06 15:16 ` [PATCH 2/4 v2] " Hans-Christian Egtvedt
2011-06-06 15:24 ` Ralf Baechle
2011-06-06 18:43 ` Mike Frysinger
2011-06-06 20:30 ` Chris Metcalf
2011-06-06 3:58 ` [PATCH 2/4] " David Miller
2011-06-09 23:08 ` Frederic Weisbecker
2011-06-06 3:10 ` [PATCH 3/4] x86: Don't call idle notifier inside rcu extended QS Frederic Weisbecker
2011-06-06 3:10 ` [PATCH 4/4] x86: Call idle_exit() after irq_enter() Frederic Weisbecker
2011-06-06 18:12 ` [PATCH 0/4] rcu: Detect rcu uses under extended quiescent state, and fix some Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110607001905.GE17026@somewhere.redhat.com \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=miltonm@bga.com \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome