From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: paulmck@linux.vnet.ibm.com, 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, sbw@mit.edu
Subject: Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?
Date: Fri, 6 Sep 2013 18:40:18 +0200 [thread overview]
Message-ID: <20130906164016.GB2706@somewhere> (raw)
In-Reply-To: <20130906113320.46b2ea3e@gandalf.local.home>
On Fri, Sep 06, 2013 at 11:33:20AM -0400, Steven Rostedt wrote:
> On Fri, 6 Sep 2013 08:18:52 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > On Fri, Sep 06, 2013 at 12:59:41PM +0200, Frederic Weisbecker wrote:
> > > On Thu, Sep 05, 2013 at 12:52:34PM -0700, Paul E. McKenney 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>
> > > >
> > > > 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
> > > > @@ -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);
> > > > +}
> > >
> > > There is also rcu_is_cpu_idle().
> >
> > Good point, thank you! I was clearly in autonomic-reflex mode yesterday. :-/
> >
> > Here is the rcutree version:
> >
> > int rcu_is_cpu_idle(void)
> > {
> > int ret;
> >
> > preempt_disable();
> > ret = (atomic_read(&__get_cpu_var(rcu_dynticks).dynticks) & 0x1) == 0;
> > preempt_enable();
> > return ret;
> > }
> >
> > And here is the rcutiny version:
> >
> > int rcu_is_cpu_idle(void)
> > {
> > return !rcu_dynticks_nesting;
> > }
> >
> > Steve, could you please use rcu_is_cpu_idle()? I will revert yesterday's
> > redundancy.
> >
>
> I can't use plain preempt_disable() in function tracing.
>
> Also, since it's a misnomer to say the cpu is idle in NO_HZ_FULL when
> we are coming from userspace, can we rename that?
>
> Perhaps we can also have a __rcu_is_cpu_tracking() (or whatever), with
> the "__" appended that does not do the preempt disable.
rcu_is_cpu_eqs() is probably better. It refers to other related "eqs" naming
in RCU APIs.
> -- Steve
next prev parent reply other threads:[~2013-09-06 16:40 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
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 [this message]
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=20130906164016.GB2706@somewhere \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.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=paulmck@linux.vnet.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox