From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, dhowells@redhat.com, edumazet@google.com,
darren@dvhart.com, fweisbec@gmail.com, sbw@mit.edu
Subject: Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?
Date: Thu, 5 Sep 2013 13:59:59 -0700 [thread overview]
Message-ID: <20130905205959.GN3966@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130905162558.6f13add0@gandalf.local.home>
On Thu, Sep 05, 2013 at 04:25:58PM -0400, Steven Rostedt wrote:
> On Thu, 5 Sep 2013 12:52:34 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > There is currently no way for kernel code to determine whether it
> > is safe to enter an RCU read-side critical section, in other words,
> > whether or not RCU is paying attention to the currently running CPU.
> > Given the large and increasing quantity of code shared by the idle loop
> > and non-idle code, the this shortcoming is becoming increasingly painful.
> >
> > This commit therefore adds rcu_watching_this_cpu(), which returns true
> > if it is safe to enter an RCU read-side critical section on the currently
> > running CPU. This function is quite fast, using only a __this_cpu_read().
> > However, the caller must disable preemption.
> >
> > Reported-by: Steven Rostedt <rostedt@goodmis.org>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> Thanks Paul!
>
> >
> > include/linux/rcupdate.h | 1 +
> > kernel/rcutree.c | 12 ++++++++++++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 15d33d9..1c7112c 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -225,6 +225,7 @@ extern void rcu_idle_enter(void);
> > extern void rcu_idle_exit(void);
> > extern void rcu_irq_enter(void);
> > extern void rcu_irq_exit(void);
> > +extern bool rcu_watching_this_cpu(void);
> >
> > #ifdef CONFIG_RCU_USER_QS
> > extern void rcu_user_enter(void);
> > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > index a06d172..7b8fcee 100644
> > --- a/kernel/rcutree.c
> > +++ b/kernel/rcutree.c
>
> Don't we also need a rcutiny version too? Otherwise I'm guessing that
> it wont compile if I use it with rcutiny (even if it always returns
> true).
Yep, there needs to be an rcutiny version, and it must work in the
same way. So what I currently have is that the rcutiny version is under
CONFIG_RCU_TRACE. This will require some Kconfig monkeying somewhere
to select CONFIG_RCU_TRACE if CONFIG_SMP and tracing is enabled.
Just trying to keep rcutiny tiny...
Thanx, Paul
> -- Steve
>
> > @@ -710,6 +710,18 @@ EXPORT_SYMBOL_GPL(rcu_lockdep_current_cpu_online);
> > #endif /* #if defined(CONFIG_PROVE_RCU) && defined(CONFIG_HOTPLUG_CPU) */
> >
> > /**
> > + * rcu_watching_this_cpu - are RCU read-side critical sections safe?
> > + *
> > + * Return true if RCU is watching the running CPU, which means that this
> > + * CPU can safely enter RCU read-side critical sections. The caller must
> > + * have at least disabled preemption.
> > + */
> > +bool rcu_watching_this_cpu(void)
> > +{
> > + return !!__this_cpu_read(rcu_dynticks.dynticks_nesting);
> > +}
> > +
> > +/**
> > * rcu_is_cpu_rrupt_from_idle - see if idle or immediately interrupted from idle
> > *
> > * If the current CPU is idle or running at a first-level (not nested)
>
next prev parent reply other threads:[~2013-09-05 21:37 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-05 19:52 [PATCH] rcu: Is it safe to enter an RCU read-side critical section? Paul E. McKenney
2013-09-05 20:25 ` Steven Rostedt
2013-09-05 20:59 ` Paul E. McKenney [this message]
2013-09-05 21:05 ` Paul E. McKenney
2013-09-05 23:40 ` Steven Rostedt
2013-09-06 10:59 ` Frederic Weisbecker
2013-09-06 15:18 ` Paul E. McKenney
2013-09-06 15:33 ` Steven Rostedt
2013-09-06 16:40 ` Frederic Weisbecker
2013-09-06 16:52 ` Steven Rostedt
2013-09-06 16:58 ` Paul E. McKenney
2013-09-06 17:00 ` Frederic Weisbecker
2013-09-06 17:16 ` Steven Rostedt
2013-09-06 17:52 ` Paul E. McKenney
2013-09-06 17:56 ` Paul E. McKenney
2013-09-06 18:21 ` Steven Rostedt
2013-09-07 0:49 ` Paul E. McKenney
2013-09-07 1:19 ` Mathieu Desnoyers
2013-09-08 1:55 ` Paul E. McKenney
2013-09-09 10:56 ` Peter Zijlstra
2013-09-06 17:21 ` Eric Dumazet
2013-09-06 17:41 ` Paul E. McKenney
2013-09-06 18:59 ` Frederic Weisbecker
2013-09-06 20:38 ` Paul E. McKenney
2013-09-09 10:53 ` Peter Zijlstra
2013-09-09 12:13 ` Frederic Weisbecker
2013-09-09 12:39 ` Steven Rostedt
2013-09-09 12:45 ` Frederic Weisbecker
2013-09-09 12:55 ` Steven Rostedt
2013-09-09 13:08 ` Frederic Weisbecker
2013-09-09 13:21 ` Steven Rostedt
2013-09-09 13:29 ` Paul E. McKenney
2013-09-09 13:29 ` Steven Rostedt
2013-09-09 13:37 ` Peter Zijlstra
2013-09-09 13:48 ` Paul E. McKenney
2013-09-09 14:40 ` Frederic Weisbecker
2013-09-09 15:20 ` Steven Rostedt
2013-09-09 15:39 ` Steven Rostedt
2013-09-09 16:03 ` Frederic Weisbecker
2013-09-09 16:09 ` Paul E. McKenney
2013-09-09 16:30 ` Steven Rostedt
2013-09-09 16:56 ` Paul E. McKenney
2013-09-09 16:21 ` Peter Zijlstra
2013-09-09 13:45 ` Frederic Weisbecker
2013-09-09 13:56 ` Paul E. McKenney
2013-09-09 14:16 ` Steven Rostedt
2013-09-09 16:17 ` Paul E. McKenney
2013-09-09 16:34 ` Steven Rostedt
2013-09-09 16:58 ` Paul E. McKenney
2013-09-09 17:06 ` Steven Rostedt
2013-09-09 17:45 ` Paul E. McKenney
2013-09-09 17:29 ` Mathieu Desnoyers
2013-09-09 17:56 ` Paul E. McKenney
2013-09-09 18:36 ` Steven Rostedt
2013-09-09 18:50 ` Paul E. McKenney
2013-09-09 21:40 ` Mathieu Desnoyers
2013-09-09 21:59 ` Steven Rostedt
2013-09-09 22:34 ` Paul E. McKenney
2013-09-11 14:13 ` Paul E. McKenney
2013-09-11 14:26 ` Steven Rostedt
2013-09-11 15:23 ` Paul E. McKenney
2013-09-11 15:49 ` Steven Rostedt
2013-09-11 16:03 ` Paul E. McKenney
2013-09-09 13:14 ` Peter Zijlstra
2013-09-09 13:29 ` Frederic Weisbecker
2013-09-09 13:41 ` Steven Rostedt
2013-09-09 13:49 ` Frederic Weisbecker
2013-09-09 13:50 ` Paul E. McKenney
2013-09-09 13:46 ` Paul E. McKenney
2013-09-09 13:55 ` Steven Rostedt
2013-09-09 16:22 ` Paul E. McKenney
2013-09-09 16:40 ` Steven Rostedt
2013-09-09 17:45 ` Paul E. McKenney
2013-09-09 13:23 ` Paul E. McKenney
2013-09-09 13:36 ` Peter Zijlstra
2013-09-09 13:53 ` Paul E. McKenney
2013-09-09 16:18 ` Peter Zijlstra
2013-09-09 14:49 ` Christoph Lameter
2013-09-09 15:08 ` Peter Zijlstra
2013-09-09 15:24 ` Christoph Lameter
2013-09-09 15:41 ` Steven Rostedt
2013-09-09 15:47 ` Steven Rostedt
2013-09-09 16:00 ` Ingo Molnar
2013-09-09 16:03 ` Steven Rostedt
2013-09-09 16:11 ` Ingo Molnar
2013-09-10 21:37 ` Christoph Lameter
2013-09-12 6:39 ` Ingo Molnar
2013-09-12 14:20 ` Christoph Lameter
2013-09-10 21:28 ` Christoph Lameter
2013-09-12 6:38 ` Ingo Molnar
2013-09-12 14:43 ` Christoph Lameter
2013-09-09 16:15 ` Peter Zijlstra
2013-09-10 4:07 ` Mike Galbraith
2013-09-09 13:36 ` Steven Rostedt
2013-09-09 14:21 ` Peter Zijlstra
2013-09-09 16:26 ` Paul E. McKenney
2013-09-09 16:42 ` Steven Rostedt
2013-09-09 16:59 ` 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=20130905205959.GN3966@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sbw@mit.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.