All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: 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,
	peterz@infradead.org, 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: Wed, 21 Feb 2018 20:13:57 -0800	[thread overview]
Message-ID: <20180222041357.GB2855@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180222032349.klcuiq23f52sfop6@tardis>

On Thu, Feb 22, 2018 at 11:23:49AM +0800, Boqun Feng wrote:
> On Tue, Feb 20, 2018 at 03:25:10PM -0800, Paul E. McKenney wrote:
> > From: Alan Stern <stern@rowland.harvard.edu>
> > 
> > This commit adds a litmus test in which P0() and P1() form a lock-based S
> > litmus test, with the addition of P2(), which observes P0()'s and P1()'s
> > accesses with a full memory barrier but without the lock.  This litmus
> > test asks whether writes carried out by two different processes under the
> > same lock will be seen in order by a third process not holding that lock.
> > The answer to this question is "yes" for all architectures supporting
> 
> Hmm.. it this true? Our spin_lock() is RCpc because of PowerPC, so
> spin_lock()+spin_unlock() pairs don't provide transitivity, and that's
> why we have smp_mb__after_unlock_lock(). Is there something I'm missing?
> Or there is an upcomming commit to switch PowerPC's lock implementation?

The PowerPC lock implementation's unlock-lock pair does not order writes
from the previous critical section against reads from the later critical
section, but it does order other combinations of reads and writes.
Some have apparently said that RISC-V 's unlock-lock pair also does not
order writes from the previous critical section against writes from the
later critical section.  And no, I don't claim to have yet gotten my
head around RISC-V memory ordering.  ;-)

							Thanx, Paul

> [Cc ppc maintainers]
> 
> Regards,
> Boqun
> 
> > the Linux kernel, but is "no" according to the current version of LKMM.
> > 
> > A patch to LKMM is under development.
> > 
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> >  .../ISA2+pooncelock+pooncelock+pombonce.litmus     | 41 ++++++++++++++++++++++
> >  1 file changed, 41 insertions(+)
> >  create mode 100644 tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus
> > 
> > diff --git a/tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus b/tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus
> > new file mode 100644
> > index 000000000000..7a39a0aaa976
> > --- /dev/null
> > +++ b/tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus
> > @@ -0,0 +1,41 @@
> > +C ISA2+pooncelock+pooncelock+pombonce.litmus
> > +
> > +(*
> > + * Result: Sometimes
> > + *
> > + * This test shows that the ordering provided by a lock-protected S
> > + * litmus test (P0() and P1()) are not visible to external process P2().
> > + * This is likely to change soon.
> > + *)
> > +
> > +{}
> > +
> > +P0(int *x, int *y, spinlock_t *mylock)
> > +{
> > +	spin_lock(mylock);
> > +	WRITE_ONCE(*x, 1);
> > +	WRITE_ONCE(*y, 1);
> > +	spin_unlock(mylock);
> > +}
> > +
> > +P1(int *y, int *z, spinlock_t *mylock)
> > +{
> > +	int r0;
> > +
> > +	spin_lock(mylock);
> > +	r0 = READ_ONCE(*y);
> > +	WRITE_ONCE(*z, 1);
> > +	spin_unlock(mylock);
> > +}
> > +
> > +P2(int *x, int *z)
> > +{
> > +	int r1;
> > +	int r2;
> > +
> > +	r2 = READ_ONCE(*z);
> > +	smp_mb();
> > +	r1 = READ_ONCE(*x);
> > +}
> > +
> > +exists (1:r0=1 /\ 2:r2=1 /\ 2:r1=0)
> > -- 
> > 2.5.2
> > 

  reply	other threads:[~2018-02-22  4:13 UTC|newest]

Thread overview: 53+ 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-21 10:39   ` [tip:locking/core] " tip-bot for Andrea Parri
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 02/12] MAINTAINERS: Add the Memory Consistency Model subsystem Paul E. McKenney
2018-02-21 10:39   ` [tip:locking/core] " tip-bot for Andrea Parri
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-21 10:40   ` [tip:locking/core] " tip-bot for Andrea Parri
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 04/12] EXP litmus_tests: Add comments explaining tests' purposes Paul E. McKenney
2018-02-21 10:40   ` [tip:locking/core] " tip-bot for 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-21 10:41   ` [tip:locking/core] " tip-bot for 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-21 10:41   ` [tip:locking/core] " tip-bot for 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-21 10:42   ` [tip:locking/core] " tip-bot for Andrea Parri
2018-02-20 23:25 ` [PATCH RFC tools/lkmm 08/12] memory-barriers: Fix description of data dependency barriers Paul E. McKenney
2018-02-21 10:42   ` [tip:locking/core] " tip-bot for Nikolay Borisov
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 10:43   ` [tip:locking/core] " tip-bot for Paul E. McKenney
2018-02-21 15:10   ` [PATCH RFC tools/lkmm 09/12] " Alan Stern
2018-02-21 15:10     ` Alan Stern
2018-02-21 16:15     ` Paul E. McKenney
2018-02-21 16:51       ` Alan Stern
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 10:43   ` [tip:locking/core] " tip-bot for Alan Stern
2018-02-21 15:09   ` [PATCH RFC tools/lkmm 10/12] " Alan Stern
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 16:50         ` Alan Stern
2018-02-21 17:53         ` Paul E. McKenney
2018-02-21 18:38           ` Alan Stern
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 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 [this message]
2018-02-22  5:27       ` Boqun Feng
2018-02-22  5:42         ` Daniel Lustig
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
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-21 10:44   ` [tip:locking/core] " tip-bot for 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
2018-02-21 10:45   ` [tip:locking/core] " tip-bot for Alan Stern

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=20180222041357.GB2855@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akiyks@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.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=paulus@samba.org \
    --cc=peterz@infradead.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 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.