Re: [PATCH 4/4] exit: Lockless iteration over task list in mm_update_next_owner()

From: Andrea Parri
Date: Thu Apr 26 2018 - 11:30:13 EST

On Thu, Apr 26, 2018 at 04:52:39PM +0300, Kirill Tkhai wrote:
> On 26.04.2018 15:35, Andrea Parri wrote:


> >
> > Mmh, it's possible that I am misunderstanding this statement but it does
> > not seem quite correct to me; a counter-example would be provided by the
> > test at "tools/memory-model/litmus-tests/SB+mbonceonces.litmus" (replace
> > either of the smp_mb() with the sequence:
> >
> > spin_lock(s); spin_unlock(s); spin_lock(s); spin_unlock(s); ).
> >
> > BTW, your commit message suggests that your case would work with "imply
> > an smp_wmb()". This implication should hold "w.r.t. current implementa-
> > tions". We (LKMM people) discussed changes to the LKMM to make it hold
> > in LKMM but such changes are still in our TODO list as of today...
> I'm not close to LKMM, so the test you referenced is not clear for me.

The test could be concisely described by:

{initially: x=y=0; }

Thread0 Thread1

x = 1; y = 1;
r0 = y; r1 = x;

Can r0,r1 be both 0 after joining?

The answer to the question is -No-; however, if you replaced any of the
MB with the locking sequence described above, then the answer is -Yes-:
full fences on both sides are required to forbid that state and this is
something that the locking sequences won't be able to provide (think at
the implementation of these primitives for powerpc, for example).

> Does LKMM show the real hardware behavior? Or there are added the most
> cases, and work is still in progress?

Very roughly speaking, LKMM is an "envelope" of the underlying hardware
memory models/architectures supported by the Linux kernel which in turn
may not coincide with the observable behavior on a given implementation
/processor of that architecture. Also, LKMM doesn't aim to be a "tight"
envelope. I'd refer to the documentation within "tools/memory-model/";
please let me know if I can provide further info.

> In the patch I used the logic, that the below code:
> x = A;
> spin_lock();
> spin_unlock();
> spin_lock();
> spin_unlock();
> y = B;
> cannot reorder much than:
> spin_lock();
> x = A; <- this can't become visible later, that spin_unlock()
> spin_unlock();
> spin_lock();
> y = B; <- this can't become visible earlier, than spin_lock()
> spin_unlock();
> Is there a problem?

As mentioned in the previous email, if smp_wmb() is what you're looking
for then this should be fine (considering current implementations; LKMM
will likely be there soon...).

BTW, the behavior in question has been recently discussed on the list;
c.f., for example, the test "unlock-lock-write-ordering" described in:

as well as

("riscv/spinlock: Strengthen implementations with fences")


> Kirill