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:4.241 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site