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
