lkml.org 
[lkml]   [2018]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 4/4] exit: Lockless iteration over task list in mm_update_next_owner()
From
Date
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@gmail.com
>
> 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

\
 
 \ /
  Last update: 2018-04-26 18:11    [W:0.140 / U:4.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site