From: Peter Zijlstra <peterz@infradead.org>
To: Daniel Lustig <dlustig@nvidia.com>
Cc: Boqun Feng <boqun.feng@gmail.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
mingo@kernel.org, stern@rowland.harvard.edu,
parri.andrea@gmail.com, will.deacon@arm.com, npiggin@gmail.com,
dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr,
akiyks@gmail.com, nborisov@suse.com,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test
Date: Thu, 22 Feb 2018 11:06:36 +0100 [thread overview]
Message-ID: <20180222100636.GP25201@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <fad8e18b-ef5a-5bc0-5d87-6fad2e9f7c95@nvidia.com>
On Wed, Feb 21, 2018 at 09:42:08PM -0800, Daniel Lustig wrote:
> And yes, if we go with a purely RCpc interpretation of acquire and
> release, then I don't believe the writes in the previous critical
> section would be ordered with the writes in the subsequent critical
> section.
Excuse my ignorance (also jumping in the middle of things), but how can
this be?
spin_unlock() is a store-release, this means the write to the lock word
must happen after any stores inside the critical section.
spin_lock() is a load-acquire + test-and-set-ctrl-dep, we'll only
proceed with the critical section if we observe the lock 'unlocked',
which also means we must observe the stores prior to the unlock.
And both the ctrl-dep and the ACQUIRE ensure future stores cannot happen
before.
So while the lock store and subsequent critical section stores are
unordered, I don't see how it would be possible to not be ordered
against stores from a previous critical section.
next prev parent reply other threads:[~2018-02-22 10:07 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-20 23:24 [PATCH RFC tools/lkmm 0/12] Miscellaneous fixes Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 01/12] tools/memory-model: Clarify the origin/scope of the tool name Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 02/12] MAINTAINERS: Add the Memory Consistency Model subsystem Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 03/12] MAINTAINERS: List file memory-barriers.txt within the LKMM entry Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 04/12] EXP litmus_tests: Add comments explaining tests' purposes Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 05/12] README: Fix a couple of punctuation errors Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 06/12] MAINTAINERS: Add Akira Yokosawa as an LKMM reviewer Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 07/12] Documentation/memory-barriers.txt: Cross-reference "tools/memory-model/" Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 08/12] memory-barriers: Fix description of data dependency barriers Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 09/12] tools/memory-model: Add required herd7 version to README file Paul E. McKenney
2018-02-21 15:10 ` Alan Stern
2018-02-21 16:15 ` Paul E. McKenney
2018-02-21 16:51 ` Alan Stern
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test Paul E. McKenney
2018-02-21 15:09 ` Alan Stern
2018-02-21 16:12 ` Paul E. McKenney
2018-02-21 16:50 ` Alan Stern
2018-02-21 17:53 ` Paul E. McKenney
2018-02-21 18:38 ` Alan Stern
2018-02-21 19:05 ` Paul E. McKenney
2018-02-21 19:27 ` Alan Stern
2018-02-21 22:25 ` Paul E. McKenney
2018-02-22 3:23 ` Boqun Feng
2018-02-22 4:13 ` Paul E. McKenney
2018-02-22 5:27 ` Boqun Feng
2018-02-22 5:42 ` Daniel Lustig
2018-02-22 6:58 ` Boqun Feng
2018-02-22 10:15 ` Peter Zijlstra
2018-02-22 10:45 ` Boqun Feng
2018-02-22 11:59 ` Peter Zijlstra
2018-02-22 10:06 ` Peter Zijlstra [this message]
2018-02-22 10:20 ` Peter Zijlstra
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 11/12] tools/memory-model: Convert underscores to hyphens Paul E. McKenney
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 12/12] tools/memory-model: Remove rb-dep, smp_read_barrier_depends, and lockless_dereference 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=20180222100636.GP25201@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akiyks@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=nborisov@suse.com \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).