From: Alan Stern <stern@rowland.harvard.edu>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Frederic Weisbecker <frederic@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Josh Triplett <josh@joshtriplett.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Marco Elver <elver@google.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
rcu <rcu@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>,
"Uladzislau Rezki \(Sony\)" <urezki@gmail.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Neeraj upadhyay <neeraj.iitr10@gmail.com>
Subject: Re: [PATCH v7 6/6] rcu/segcblist: Add additional comments to explain smp_mb()
Date: Sun, 18 Oct 2020 17:15:53 -0400 [thread overview]
Message-ID: <20201018211553.GA872947@rowland.harvard.edu> (raw)
In-Reply-To: <CAEXW_YQ--s-0aYGFtO46ptf9y9LjoRhXvv3Ksk-QTYpLQYGaJg@mail.gmail.com>
On Sun, Oct 18, 2020 at 01:45:31PM -0700, Joel Fernandes wrote:
> Hi,
> Thanks Alan for your replies.
You're welcome.
> > > C rcubarrier+ctrldep
> > >
> > > (*
> > > * Result: Never
> > > *
> > > * This litmus test shows that rcu_barrier (P1) prematurely
> > > * returning by reading len 0 can cause issues if P0 does
> > > * NOT have a smb_mb() after WRITE_ONCE(len, 1).
> > > * mod_data == 2 means module was unloaded (so data is garbage).
> > > *)
> > >
> > > { int len = 0; int enq = 0; }
> > >
> > > P0(int *len, int *mod_data, int *enq)
> > > {
> > > int r0;
> > >
> > > WRITE_ONCE(*len, 1);
> > > smp_mb(); /* Needed! */
> > > WRITE_ONCE(*enq, 1);
> > >
> > > r0 = READ_ONCE(*mod_data);
> > > }
> > >
> > > P1(int *len, int *mod_data, int *enq)
> > > {
> > > int r0;
> > > int r1;
> > >
> > > r1 = READ_ONCE(*enq);
> > >
> > > // barrier Just for test purpose ("exists" clause) to force the..
> > > // ..rcu_barrier() to see enq before len
> > > smp_mb();
> > > r0 = READ_ONCE(*len);
> > >
> > > // implicit memory barrier due to conditional */
> > > if (r0 == 0)
> > > WRITE_ONCE(*mod_data, 2);
> > > }
> > >
> > > // Did P0 read garbage?
> > > exists (0:r0=2 /\ 1:r0=0 /\ 1:r1=1)
> >
> > Is this exists clause really what you meant? Not only can it not be
> > satisfied, it couldn't even be satisfied if you left out the 0:r0=2
> > part. And smp_mb() is stronger than neessary to enforce this.
>
> This is indeed what I meant.
>
> Maybe the exists clause can be simplified, but I just wanted to
> enforce that P1 saw P0's write to enq before seeing anything else.
>
> Per my test, if you remove the smp_mb() in P0, the test will fail.
>
> What I wanted to show was P0() seeing mod_data == 2 is bad and should
> never happen (as that implies rcu_barrier() saw len == 0 when it
> should not have). Maybe you can point out what is my test missing?
That's a little tricky, since I don't understand what the test is trying
to say.
For example, you could change the exists clause to omit "/\ 1:r1=1".
Maybe that's not a meaningful thing to do... but then it could be
satisfied simply by having P1 run to completion before P0 starts.
Or you could leave the exists clause as it is and remove the smp_mb()
from P0. As you said, that version of the test would also fail since P0
could then reorder its two writes.
> > However, some memory barrier is needed. If the smp_mb() in P1 were
> > omitted then P1 would be free to reorder its reads, and the exists
> > clause could be satisfied as follows:
> >
> > P0 P1
> > ------------------------------------------
> > Read len = 0
> > Write len = 1
> > smp_mb();
> > Write enq = 1
> > Read enq = 1
> > Write mod_data = 2
> > Read mod_data = 2
>
> Right, so I think I got it right then. I want to show that the control
> dependency in P1 provides the needed ordering. The extra smp_mb() I
> added was just so that I could force P1 to see P0's enqueue.
Yes, it's quite correct that because of the control dependency, P1
cannot write mod_data before it reads the value of len.
Alan Stern
next prev parent reply other threads:[~2020-10-18 21:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 0:22 [PATCH v7 0/6] Add support for length of each segment in the segcblist Joel Fernandes (Google)
2020-10-15 0:22 ` [PATCH v7 1/6] rcu/tree: Make rcu_do_batch count how many callbacks were executed Joel Fernandes (Google)
2020-10-15 0:22 ` [PATCH v7 2/6] rcu/segcblist: Add counters to segcblist datastructure Joel Fernandes (Google)
2020-10-15 12:21 ` Frederic Weisbecker
2020-10-17 1:31 ` joel
2020-10-21 15:33 ` joel
2020-10-21 21:53 ` Frederic Weisbecker
2020-10-21 22:31 ` Joel Fernandes
2020-10-18 8:23 ` [rcu/segcblist] e08055898f: WARNING:at_kernel/rcu/srcutree.c:#cleanup_srcu_struct kernel test robot
2020-10-21 14:40 ` joel
2020-10-15 0:22 ` [PATCH v7 3/6] rcu/trace: Add tracing for how segcb list changes Joel Fernandes (Google)
2020-10-15 0:22 ` [PATCH v7 4/6] rcu/segcblist: Remove useless rcupdate.h include Joel Fernandes (Google)
2020-10-15 0:23 ` [PATCH v7 5/6] rcu/tree: Remove redundant smp_mb() in rcu_do_batch Joel Fernandes (Google)
2020-10-15 0:23 ` [PATCH v7 6/6] rcu/segcblist: Add additional comments to explain smp_mb() Joel Fernandes (Google)
2020-10-15 13:35 ` Frederic Weisbecker
2020-10-17 1:27 ` joel
2020-10-17 3:19 ` joel
2020-10-17 13:29 ` Frederic Weisbecker
2020-10-18 0:35 ` joel
2020-10-19 12:37 ` Frederic Weisbecker
2020-10-21 18:57 ` Joel Fernandes
2020-10-21 21:16 ` Frederic Weisbecker
2020-10-17 20:24 ` Alan Stern
2020-10-18 20:45 ` Joel Fernandes
2020-10-18 21:15 ` Alan Stern [this message]
2020-10-17 14:31 ` Alan Stern
2020-10-18 20:16 ` Joel Fernandes
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=20201018211553.GA872947@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=elver@google.com \
--cc=frederic@kernel.org \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=neeraj.iitr10@gmail.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=urezki@gmail.com \
/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
all inboxes | Powered by JetHome®