linux-kernel - Re: [PATCH 4/4] exit: Lockless iteration over task list in mm_update_next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Apr 2018 19:11:42 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     Andrea Parri <andrea.parri@...rulasolutions.com>
Cc:     akpm@...ux-foundation.org, peterz@...radead.org, oleg@...hat.com,
        viro@...iv.linux.org.uk, mingo@...nel.org,
        paulmck@...ux.vnet.ibm.com, keescook@...omium.org, riel@...hat.com,
        mhocko@...e.com, tglx@...utronix.de,
        kirill.shutemov@...ux.intel.com, marcos.souza.org@...il.com,
        hoeun.ryu@...il.com, pasha.tatashin@...cle.com, gs051095@...il.com,
        ebiederm@...ssion.com, dhowells@...hat.com,
        rppt@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
        Alan Stern <stern@...land.harvard.edu>,
        Will Deacon <will.deacon@....com>,
        Boqun Feng <boqun.feng@...il.com>
Subject: Re: [PATCH 4/4] exit: Lockless iteration over task list in
 mm_update_next_owner()

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