From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Joel Fernandes <joelaf@google.com>,
linux-kernel@vger.kernel.org,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
byungchul.park@lge.com, kernel-team@android.com
Subject: Re: [PATCH v3 4/4] rcu: Unlock non-start node only after accessing its gp_seq_needed
Date: Tue, 22 May 2018 05:12:16 -0700 [thread overview]
Message-ID: <20180522121216.GR3803@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180522044327.GF40541@joelaf.mtv.corp.google.com>
On Mon, May 21, 2018 at 09:43:27PM -0700, Joel Fernandes wrote:
> On Mon, May 21, 2018 at 09:16:51PM -0700, Paul E. McKenney wrote:
> > On Mon, May 21, 2018 at 05:28:23PM -0700, Paul E. McKenney wrote:
> > > On Mon, May 21, 2018 at 05:07:34PM -0700, Joel Fernandes wrote:
> > > > On Mon, May 21, 2018 at 04:25:38PM -0700, Paul E. McKenney wrote:
> > > > > On Sun, May 20, 2018 at 09:42:20PM -0700, Joel Fernandes wrote:
> > > > > > We acquire gp_seq_needed locklessly. To be safe, lets do the unlocking
> > > > > > after the access.
> > > > >
> > > > > Actually, no, we hold rnp_start's ->lock throughout. And this CPU (or in
> > > > > the case of no-CBs CPUs, this task) is in charge of rdp->gp_seq_needed,
> > > > > so nothing else is accessing it. Or at least that is the intent. ;-)
> > > >
> > > > I was talking about protecting the internal node's rnp->gp_seq_needed, not
> > > > the rnp_start's gp_seq_needed.
> > >
> > > Ah, good point, I missed the "if" condition. This can be argued to work,
> > > sort of, given that we still hold the leaf rcu_node structure's lock,
> > > so that there is a limit to how far grace periods can advance.
> > >
> > > But the code would of course be much cleaner with your change.
> > >
> > > > We are protecting them in the loop:
> > > >
> > > > like this:
> > > > for(...)
> > > > if (rnp != rnp_start)
> > > > raw_spin_lock_rcu_node(rnp);
> > > > [...]
> > > > // access rnp->gp_seq and rnp->gp_seq_needed
> > > > [...]
> > > > if (rnp != rnp_start)
> > > > raw_spin_unlock_rcu_node(rnp);
> > > >
> > > > But we don't need to do such protection in unlock_out ? I'm sorry if I'm
> > > > missing something, but I'm wondering if rnp->gp_seq_needed of an internal
> > > > node can be accessed locklessly, then why can't that be done also in the
> > > > funnel locking loop - after all we are holding the rnp_start's lock through
> > > > out right?
> > >
> > > I was focused on the updates, and missed the rnp->gp_seq_req access in the
> > > "if" statement. The current code does sort of work, but only assuming
> > > that the compiler doesn't tear the load, and so your change would help.
> > > Could you please resend with your other two updated patches? It depends
> > > on one of the earlier patches, so does not apply cleanly as-is. I could
> > > hand-apply it, but that sounds like a good way to make your updated
> > > series fail to apply. ;-)
> > >
> > > But could you also make the commit log explicitly call out the "if"
> > > condition as being the offending access?
> >
> > Never mind, me being stupid. I need to apply this change to the original
> > commit "rcu: Make rcu_nocb_wait_gp() check if GP already requested", which
> > I have done with this attribution:
> >
> > [ paulmck: Move lock release past "if" as suggested by Joel Fernandes. ]
> >
> > I have rebased my stack on top of the updated commit.
>
> Cool, makes sense. I am assuming this means I don't have to resend this
> patch, if I do let me know :)
No need.
> Either way, once you push your updated tree to kernel.org, I'll double check
> to make sure the change is in :)
Please see 9624746baf6b ("rcu: Make rcu_nocb_wait_gp() check if GP
already requested") on branch rcu/dev.
Thanx, Paul
prev parent reply other threads:[~2018-05-22 14:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-21 4:42 [PATCH v3 0/4] fixes, cleanups for rcu/dev Joel Fernandes
2018-05-21 4:42 ` [PATCH v3 1/4] rcu: Add comment documenting how rcu_seq_snap works Joel Fernandes
2018-05-21 4:50 ` Randy Dunlap
2018-05-21 5:48 ` Joel Fernandes
2018-05-21 6:18 ` Randy Dunlap
2018-05-21 9:35 ` Joe Perches
2018-05-21 23:42 ` Paul E. McKenney
2018-05-21 4:42 ` [PATCH v3 2/4] rcu: Cleanup the variables used to request a new grace period Joel Fernandes
2018-05-21 23:39 ` Paul E. McKenney
2018-05-21 23:41 ` Joel Fernandes
2018-05-21 4:42 ` [PATCH v3 3/4] rcu: Use better variable names in funnel locking loop Joel Fernandes
2018-05-21 23:13 ` Paul E. McKenney
2018-05-22 0:00 ` Joel Fernandes
2018-05-22 0:19 ` Paul E. McKenney
2018-05-22 0:19 ` Joel Fernandes
2018-05-22 0:29 ` Paul E. McKenney
2018-05-21 4:42 ` [PATCH v3 4/4] rcu: Unlock non-start node only after accessing its gp_seq_needed Joel Fernandes
2018-05-21 23:25 ` Paul E. McKenney
2018-05-22 0:07 ` Joel Fernandes
2018-05-22 0:28 ` Paul E. McKenney
2018-05-22 4:16 ` Paul E. McKenney
2018-05-22 4:43 ` Joel Fernandes
2018-05-22 12:12 ` Paul E. McKenney [this message]
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=20180522121216.GR3803@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=byungchul.park@lge.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=joelaf@google.com \
--cc=josh@joshtriplett.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--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