Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

[Boqun Feng]

On Wed, Feb 21, 2018 at 08:13:57PM -0800, Paul E. McKenney wrote:
> 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@xxxxxxxxxxxxxxxxxxx>
> > > 
> > > 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.

Ah.. right! Thanks for the explanation ;-)

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

Me neither. Now I remember this: we have a off-list(accidentally)
discussion about this, and IIRC at that moment riscv people confirmed
that riscv's unlock-lock pair doesn't order write->write, but that was
before their memory model draft posted for discussions, so things may
change now... 

Besides, I think the smp_mb() on P2 can be relaxed to smp_rmb(), no?

Regards,
Boqun

> 							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@xxxxxxxxxxxxxxxxxxx>
> > > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> > > ---
> > >  .../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
> > > 
> 
>

Attachment: signature.asc
Description: PGP signature