lkml.org 
[lkml]   [2018]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
    From
    Date
    On 7/9/2018 1:01 PM, Alan Stern wrote:
    > More than one kernel developer has expressed the opinion that the LKMM
    > should enforce ordering of writes by locking. In other words, given
    > the following code:
    >
    > WRITE_ONCE(x, 1);
    > spin_unlock(&s):
    > spin_lock(&s);
    > WRITE_ONCE(y, 1);
    >
    > the stores to x and y should be propagated in order to all other CPUs,
    > even though those other CPUs might not access the lock s. In terms of
    > the memory model, this means expanding the cumul-fence relation.
    >
    > Locks should also provide read-read (and read-write) ordering in a
    > similar way. Given:
    >
    > READ_ONCE(x);
    > spin_unlock(&s);
    > spin_lock(&s);
    > READ_ONCE(y); // or WRITE_ONCE(y, 1);
    >
    > the load of x should be executed before the load of (or store to) y.
    > The LKMM already provides this ordering, but it provides it even in
    > the case where the two accesses are separated by a release/acquire
    > pair of fences rather than unlock/lock. This would prevent
    > architectures from using weakly ordered implementations of release and
    > acquire, which seems like an unnecessary restriction. The patch
    > therefore removes the ordering requirement from the LKMM for that
    > case.
    >
    > All the architectures supported by the Linux kernel (including RISC-V)
    > do provide this ordering for locks, albeit for varying reasons.
    > Therefore this patch changes the model in accordance with the
    > developers' wishes.
    >
    > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    >
    > ---
    >
    > v.2: Restrict the ordering to lock operations, not general release
    > and acquire fences.
    >
    > [as1871b]
    >
    >
    > tools/memory-model/Documentation/explanation.txt | 186 +++++++---
    > tools/memory-model/linux-kernel.cat | 8
    > tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus | 5
    > 3 files changed, 149 insertions(+), 50 deletions(-)
    >
    > Index: usb-4.x/tools/memory-model/linux-kernel.cat
    > ===================================================================
    > --- usb-4.x.orig/tools/memory-model/linux-kernel.cat
    > +++ usb-4.x/tools/memory-model/linux-kernel.cat
    > @@ -38,7 +38,7 @@ let strong-fence = mb | gp
    > (* Release Acquire *)
    > let acq-po = [Acquire] ; po ; [M]
    > let po-rel = [M] ; po ; [Release]
    > -let rfi-rel-acq = [Release] ; rfi ; [Acquire]
    > +let unlock-rf-lock-po = [UL] ; rf ; [LKR] ; po

    It feels slightly weird that unlock-rf-lock-po is asymmetrical. And in
    fact, I think the current RISC-V solution we've been discussing (namely,
    putting a fence.tso instead of a fence rw,w in front of the release)
    may not even technically respect that particular sequence. The
    fence.tso solution really enforces "po; [UL]; rf; [LKR]", right?

    Does something like "po; [UL]; rf; [LKR]; po" fit in with the rest
    of the model? If so, maybe that solves the asymmetry and also
    legalizes the approach of putting fence.tso in front?

    Or, other suggestions?

    Dan

    > (**********************************)
    > (* Fundamental coherence ordering *)
    > @@ -60,13 +60,13 @@ let dep = addr | data
    > let rwdep = (dep | ctrl) ; [W]
    > let overwrite = co | fr
    > let to-w = rwdep | (overwrite & int)
    > -let to-r = addr | (dep ; rfi) | rfi-rel-acq
    > +let to-r = addr | (dep ; rfi)
    > let fence = strong-fence | wmb | po-rel | rmb | acq-po
    > -let ppo = to-r | to-w | fence
    > +let ppo = to-r | to-w | fence | (unlock-rf-lock-po & int)
    >
    > (* Propagation: Ordering from release operations and strong fences. *)
    > let A-cumul(r) = rfe? ; r
    > -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb
    > +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb | unlock-rf-lock-po
    > let prop = (overwrite & ext)? ; cumul-fence* ; rfe?

    \
     
     \ /
      Last update: 2018-07-10 18:56    [W:4.183 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site