From: "Paul E. McKenney" <paulmck@kernel.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Björn Töpel" <bjorn.topel@gmail.com>, bpf <bpf@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
parri.andrea@gmail.com, "Will Deacon" <will@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com,
j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com,
dlustig@nvidia.com, joel@joelfernandes.org,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>
Subject: Re: XDP socket rings, and LKMM litmus tests
Date: Wed, 3 Mar 2021 09:40:22 -0800 [thread overview]
Message-ID: <20210303174022.GD2696@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20210303171221.GA1574518@rowland.harvard.edu>
On Wed, Mar 03, 2021 at 12:12:21PM -0500, Alan Stern wrote:
> On Tue, Mar 02, 2021 at 03:50:19PM -0800, Paul E. McKenney wrote:
> > On Tue, Mar 02, 2021 at 04:14:46PM -0500, Alan Stern wrote:
>
> > > This result is wrong, apparently because of a bug in herd7. There
> > > should be control dependencies from each of the two loads in P0 to each
> > > of the two stores, but herd7 doesn't detect them.
> > >
> > > Maybe Luc can find some time to check whether this really is a bug and
> > > if it is, fix it.
> >
> > I agree that herd7's control dependency tracking could be improved.
> >
> > But sadly, it is currently doing exactly what I asked Luc to make it do,
> > which is to confine the control dependency to its "if" statement. But as
> > usual I wasn't thinking globally enough. And I am not exactly sure what
> > to ask for. Here a store to a local was control-dependency ordered after
> > a read, and so that should propagate to a read from that local variable.
> > Maybe treat local variables as if they were registers, so that from
> > herd7's viewpoint the READ_ONCE()s are able to head control-dependency
> > chains in multiple "if" statements?
> >
> > Thoughts?
>
> Local variables absolutely should be treated just like CPU registers, if
> possible. In fact, the compiler has the option of keeping local
> variables stored in registers.
>
> (Of course, things may get complicated if anyone writes a litmus test
> that uses a pointer to a local variable, Especially if the pointer
> could hold the address of a local variable in one execution and a
> shared variable in another! Or if the pointer is itself a shared
> variable and is dereferenced in another thread!)
Good point! I did miss this complication. ;-)
As you say, when its address is taken, the "local" variable needs to be
treated as is it were shared. There are exceptions where the pointed-to
local is still used only by its process. Are any of these exceptions
problematic?
> But even if local variables are treated as non-shared storage locations,
> we should still handle this correctly. Part of the problem seems to lie
> in the definition of the to-r dependency relation; the relevant portion
> is:
>
> (dep ; [Marked] ; rfi)
>
> Here dep is the control dependency from the READ_ONCE to the
> local-variable store, and the rfi refers to the following load of the
> local variable. The problem is that the store to the local variable
> doesn't go in the Marked class, because it is notated as a plain C
> assignment. (And likewise for the following load.)
>
> Should we change the model to make loads from and stores to local
> variables always count as Marked?
As long as the initial (possibly unmarked) load would be properly
complained about. And I cannot immediately think of a situation where
this approach would break that would not result in a data race being
flagged. Or is this yet another failure of my imagination?
> What should have happened if the local variable were instead a shared
> variable which the other thread didn't access at all? It seems like a
> weak point of the memory model that it treats these two things
> differently.
But is this really any different than the situation where a global
variable is only accessed by a single thread?
Thanx, Paul
next prev parent reply other threads:[~2021-03-03 20:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 18:46 XDP socket rings, and LKMM litmus tests Björn Töpel
2021-03-02 19:57 ` Paul E. McKenney
2021-03-02 20:04 ` Paul E. McKenney
2021-03-02 20:37 ` Björn Töpel
2021-03-02 20:24 ` Björn Töpel
2021-03-02 20:41 ` Paul E. McKenney
2021-03-02 20:51 ` Björn Töpel
2021-03-02 21:14 ` Alan Stern
2021-03-02 23:50 ` Paul E. McKenney
2021-03-03 6:37 ` maranget
2021-03-03 16:54 ` Paul E. McKenney
2021-03-03 17:12 ` Alan Stern
2021-03-03 17:37 ` maranget
2021-03-03 17:39 ` maranget
2021-03-03 21:56 ` Paul E. McKenney
2021-03-03 19:40 ` Alan Stern
2021-03-03 17:40 ` Paul E. McKenney [this message]
2021-03-03 20:22 ` Alan Stern
2021-03-03 22:03 ` Paul E. McKenney
2021-03-04 3:21 ` Alan Stern
2021-03-04 5:04 ` Paul E. McKenney
2021-03-04 15:35 ` Alan Stern
2021-03-04 19:05 ` Paul E. McKenney
2021-03-04 21:27 ` Alan Stern
2021-03-04 22:05 ` Paul E. McKenney
2021-03-04 1:26 ` Boqun Feng
2021-03-04 3:13 ` Alan Stern
2021-03-04 6:33 ` Boqun Feng
2021-03-04 16:11 ` Alan Stern
2021-03-05 1:12 ` Boqun Feng
2021-03-05 16:15 ` Alan Stern
2021-03-04 15:44 ` maranget
2021-03-04 19:07 ` 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=20210303174022.GD2696@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=akiyks@gmail.com \
--cc=bjorn.topel@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=magnus.karlsson@intel.com \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=toke@redhat.com \
--cc=will@kernel.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).