From: "Paul E. McKenney" <paulmck@kernel.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-kernel@vger.kernel.org,
Frederic Weisbecker <fweisbec@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Josh Triplett <josh@joshtriplett.org>,
kernel-team@android.com, Lai Jiangshan <jiangshanlai@gmail.com>,
linux-doc@vger.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
rcu@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter
Date: Thu, 29 Aug 2019 19:45:56 -0700 [thread overview]
Message-ID: <20190830024556.GZ4125@linux.ibm.com> (raw)
In-Reply-To: <20190830012036.GA184995@google.com>
On Thu, Aug 29, 2019 at 09:20:36PM -0400, Joel Fernandes wrote:
> On Thu, Aug 29, 2019 at 05:47:56PM -0700, Paul E. McKenney wrote:
> [snip]
> > > > > Paul, also what what happens in the following scenario:
> > > > >
> > > > > CPU0 CPU1
> > > > >
> > > > > A syscall causes rcu_eqs_exit()
> > > > > rcu_read_lock();
> > > > > ---> FQS loop waiting on
> > > > > dyntick_snap
> > > > > usermode-upcall entry -->causes rcu_eqs_enter();
> > > > >
> > > > > usermode-upcall exit -->causes rcu_eqs_exit();
> > > > >
> > > > > ---> FQS loop sees
> > > > > dyntick snap
> > > > > increment and
> > > > > declares CPU0 is
> > > > > in a QS state
> > > > > before the
> > > > > rcu_read_unlock!
> > > > >
> > > > > rcu_read_unlock();
> > > > > ---
> > > > >
> > > > > Does the context tracking not call rcu_user_enter() in this case, or did I
> > > > > really miss something?
> > > >
> > > > Holding rcu_read_lock() across usermode execution (in this case,
> > > > the usermode upcall) is a bad idea. Why is CPU 0 doing that?
> > >
> > > Oh, ok. I was just hypothesizing that since usermode upcalls from
> > > something as heavy as interrupts, it could also mean we had the same from
> > > some path that held an rcu_read_lock() as well. It was just a theoretical
> > > concern, if it is not an issue, no problem.
> >
> > Are there the usual lockdep checks in the upcall code? Holding a spinlock
> > across them would seem to be at least as bad as holding an rcu_read_lock()
> > across them.
>
> Great point, I'll take a look.
>
> > > The other question I had was, in which cases would dyntick_nesting in current
> > > RCU code be > 1 (after removing the lower bit and any crowbarring) ? In the
> > > scenarios I worked out on paper, I can only see this as 1 or 0. But the
> > > wording of it is 'dynticks_nesting'. May be I am missing a nesting scenario?
> > > We can exit RCU-idleness into process context only once (either exiting idle
> > > mode or user mode). Both cases would imply a value of 1.
> >
> > Interrrupt -> NMI -> certain types of tracing. I believe that can get
> > it to 5. There might be even more elaborate sequences of events.
>
> I am only talking about dynticks_nesting, not dynticks_nmi_nesting. In
> current mainline, I see this only 0 or 1. I am running the below patch
> overnight on all RCU configurations to see if it is ever any other value.
Ah! Then yes, we never enter non-idle/non-user process-level mode
twice without having exited it. There would have been a splat,
I believe.
> And, please feel free to ignore my emails as you mentioned you are supposed
> to be out next 2 days! Thanks for the replies though!
Actually this day and next. ;-)
Thanx, Paul
> ---8<-----------------------
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 68ebf0eb64c8..8c8ddb6457d5 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -571,6 +571,9 @@ static void rcu_eqs_enter(bool user)
> WRITE_ONCE(rdp->dynticks_nmi_nesting, 0);
> WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> rdp->dynticks_nesting == 0);
> +
> + WARN_ON_ONCE(rdp->dynticks_nesting != 1);
> +
> if (rdp->dynticks_nesting != 1) {
> rdp->dynticks_nesting--;
> return;
> @@ -736,6 +739,9 @@ static void rcu_eqs_exit(bool user)
> lockdep_assert_irqs_disabled();
> rdp = this_cpu_ptr(&rcu_data);
> oldval = rdp->dynticks_nesting;
> +
> + WARN_ON_ONCE(rdp->dynticks_nesting != 0);
> +
> WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && oldval < 0);
> if (oldval) {
> rdp->dynticks_nesting++;
> --
> 2.23.0.187.g17f5b7556c-goog
>
next prev parent reply other threads:[~2019-08-30 2:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 1:33 [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter Joel Fernandes (Google)
2019-08-27 1:40 ` Joel Fernandes
2019-08-28 20:23 ` Paul E. McKenney
2019-08-28 21:05 ` Joel Fernandes
2019-08-28 21:19 ` Paul E. McKenney
2019-08-28 21:42 ` Joel Fernandes
2019-08-28 22:01 ` Paul E. McKenney
2019-08-28 22:14 ` Joel Fernandes
2019-08-28 23:12 ` Paul E. McKenney
2019-08-29 1:51 ` Joel Fernandes
2019-08-29 3:43 ` Paul E. McKenney
2019-08-29 13:59 ` Joel Fernandes
2019-08-29 16:32 ` Paul E. McKenney
2019-08-29 14:43 ` Joel Fernandes
2019-08-29 15:13 ` Joel Fernandes
2019-08-29 16:13 ` Paul E. McKenney
2019-08-29 17:14 ` Joel Fernandes
2019-08-30 0:47 ` Paul E. McKenney
2019-08-30 1:20 ` Joel Fernandes
2019-08-30 2:45 ` Paul E. McKenney [this message]
2019-08-29 16:09 ` Paul E. McKenney
2019-08-29 16:21 ` Andy Lutomirski
2019-08-29 16:54 ` Paul E. McKenney
2019-08-29 19:00 ` Joel Fernandes
2019-08-30 0:48 ` 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=20190830024556.GZ4125@linux.ibm.com \
--to=paulmck@kernel.org \
--cc=corbet@lwn.net \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kernel-team@android.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mchehab+samsung@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/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;
as well as URLs for NNTP newsgroup(s).