From: Lance Roy <ldr709@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
jiangshanlai@gmail.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com,
bobby.prani@gmail.com
Subject: Re: [PATCH v2 tip/core/rcu 2/3] srcu: Force full grace-period ordering
Date: Mon, 23 Jan 2017 12:06:04 -0800 [thread overview]
Message-ID: <20170123120604.106ee644@gmail.com> (raw)
In-Reply-To: <20170123191207.GG28085@linux.vnet.ibm.com>
On Mon, 23 Jan 2017 11:12:07 -0800
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> On Mon, Jan 23, 2017 at 12:38:29AM -0800, Lance Roy wrote:
> > On Sun, 15 Jan 2017 14:42:34 -0800
> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > > @@ -413,6 +415,8 @@ static void __synchronize_srcu(struct srcu_struct *sp,
> > > int trycount)
> > > if (!done)
> > > wait_for_completion(&rcu.completion);
> > > +
> > > + smp_mb(); /* Caller's later accesses after GP. */
> >
> > I think that this memory barrier is only necessary when done == false, as
> > otherwise srcu_advance_batches() should provide sufficient memory
> > ordering.
>
> Let me make sure that I understand your rationale here.
>
> The idea is that although srcu_readers_active_idx_check() did a full
> memory barrier, this might have happened on some other CPU, which
> would not have provided ordering to the current CPU in the race case
> where current CPU didn't actually sleep. (This can happen where the
> current task is preempted, and then is resumed just as the grace period
> completes.)
>
> Or are you concerned about some other sequence of events?
Yes, the problem only occurs when the only full memory barrier is executed on a
different CPU.
> (I have moved the smp_mb() inside the "if (!done)" in the meantime.)
Thanks.
> > > @@ -587,6 +591,7 @@ static void srcu_invoke_callbacks(struct srcu_struct
> > > *sp) int i;
> > > struct rcu_head *head;
> > >
> > > + smp_mb(); /* Callback accesses after GP. */
> >
> > Shouldn't srcu_advance_batches() have already run all necessary memory
> > barriers?
>
> It does look that way:
>
> o process_srcu() is the only thing that invokes
> srcu_invoke_callbacks().
>
> o process_srcu() invokes srcu_advance_batches() immediately before
> srcu_invoke_callbacks(), so any memory barriers invoked from
> srcu_advance_batches() affect process_srcu() (unlike the earlier
> example where srcu_advance_batches() might be executed in the
> context of some other task).
>
> o srcu_advance_batches() unconditionally invokes try_check_zero(),
> which in turn unconditionally invokes srcu_readers_active_idx_check(),
> which in turn invokes smp_mb().
>
> This smp_mb() precedes a successful check that all pre-existing
> readers are done, otherwise srcu_advance_batches() won't have
> returned (or won't have advanced the callbacks, which in turn
> will prevent them from being invoked).
>
> I have removed this memory barrier and added a comment.
>
> And thank you for your review and comments!!!
Thanks,
Lance
next prev parent reply other threads:[~2017-01-23 20:06 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-14 9:19 [PATCH tip/core/rcu 0/3] SRCU updates for 4.11 Paul E. McKenney
2017-01-14 9:19 ` [PATCH tip/core/rcu 1/3] srcu: More efficient reader counts Paul E. McKenney
2017-01-14 9:31 ` Ingo Molnar
2017-01-14 19:48 ` Paul E. McKenney
2017-01-14 9:20 ` [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering Paul E. McKenney
2017-01-14 9:35 ` Ingo Molnar
2017-01-14 19:54 ` Paul E. McKenney
2017-01-14 21:41 ` Paul E. McKenney
2017-01-15 7:11 ` Ingo Molnar
2017-01-15 7:40 ` Paul E. McKenney
2017-01-15 7:57 ` Ingo Molnar
2017-01-15 9:24 ` Paul E. McKenney
2017-01-15 9:40 ` Ingo Molnar
2017-01-15 19:45 ` Paul E. McKenney
2017-01-16 6:56 ` Ingo Molnar
2017-01-23 8:12 ` Michael Ellerman
2017-01-24 2:45 ` Paul E. McKenney
2017-01-15 6:54 ` Ingo Molnar
2017-01-14 9:20 ` [PATCH tip/core/rcu 3/3] rcutorture: Add CBMC-based formal verification for SRCU Paul E. McKenney
2017-01-15 22:41 ` [PATCH tip/core/rcu v2 0/3] SRCU updates for 4.11 Paul E. McKenney
2017-01-15 22:42 ` [PATCH v2 tip/core/rcu 1/3] srcu: Implement more-efficient reader counts Paul E. McKenney
2017-01-23 20:17 ` Lance Roy
2017-01-23 20:17 ` [PATCH] SRCU: More efficient " Lance Roy
2017-01-23 20:35 ` Paul E. McKenney
2017-01-23 21:33 ` Lance Roy
2017-01-23 21:35 ` [PATCH] srcu: Implement more-efficient " Lance Roy
2017-01-24 0:42 ` Paul E. McKenney
2017-01-24 0:53 ` Lance Roy
2017-01-24 1:57 ` Paul E. McKenney
2017-01-24 3:26 ` Lance Roy
2017-01-24 17:07 ` Paul E. McKenney
2017-01-15 22:42 ` [PATCH v2 tip/core/rcu 2/3] srcu: Force full grace-period ordering Paul E. McKenney
2017-01-23 8:38 ` Lance Roy
2017-01-23 19:12 ` Paul E. McKenney
2017-01-23 20:06 ` Lance Roy [this message]
2017-01-15 22:42 ` [PATCH v2 tip/core/rcu 3/3] rcutorture: Add CBMC-based formal verification for SRCU Paul E. McKenney
2017-01-24 22:00 ` [PATCH v3 tip/core/rcu 0/4] SRCU updates for 4.11 Paul E. McKenney
2017-01-24 22:00 ` [PATCH v3 tip/core/rcu 1/4] srcu: Implement more-efficient reader counts Paul E. McKenney
2017-01-25 18:17 ` Lance Roy
2017-01-25 21:03 ` Paul E. McKenney
2017-01-24 22:00 ` [PATCH v3 tip/core/rcu 2/4] srcu: Force full grace-period ordering Paul E. McKenney
2017-01-24 22:00 ` [PATCH v3 tip/core/rcu 3/4] rcutorture: Add CBMC-based formal verification for SRCU Paul E. McKenney
2017-01-24 22:00 ` [PATCH v3 tip/core/rcu 4/4] srcu: Reduce probability of SRCU ->unlock_count[] counter overflow 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=20170123120604.106ee644@gmail.com \
--to=ldr709@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bobby.prani@gmail.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=dvhart@linux.intel.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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;
as well as URLs for NNTP newsgroup(s).