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 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.