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

[Kirill Tkhai]

On 26.04.2018 18:29, Andrea Parri wrote:
> 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;
>    MB		MB
>    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).

Ah, I see, thanks for clarifying this.
 
>> 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:
> 
>   http://lkml.kernel.org/r/1519301990-11766-1-git-send-email-parri.andrea@xxxxxxxxx
> 
> as well as
> 
>   0123f4d76ca63b7b895f40089be0ce4809e392d8
>   ("riscv/spinlock: Strengthen implementations with fences")
> 
>   Andrea

Yes, I'm looking for smp_wmb(). Read barrier is not required there.

Thanks for referring this.

Kirill