lkml.org 
[lkml]   [2018]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks
    On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
    > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
    > > More than one kernel developer has expressed the opinion that the LKMM
    > > should enforce ordering of writes by release-acquire chains and by
    > > locking. In other words, given the following code:
    > >
    > > WRITE_ONCE(x, 1);
    > > spin_unlock(&s):
    > > spin_lock(&s);
    > > WRITE_ONCE(y, 1);
    > >
    > > or the following:
    > >
    > > smp_store_release(&x, 1);
    > > r1 = smp_load_acquire(&x); // r1 = 1
    > > 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 or be part of
    > > the release-acquire chain. In terms of the memory model, this means
    > > that rel-rf-acq-po should be part of the cumul-fence relation.
    > >
    > > All the architectures supported by the Linux kernel (including RISC-V)
    > > do behave this way, albeit for varying reasons. Therefore this patch
    > > changes the model in accordance with the developers' wishes.
    >
    > Interesting...
    >
    > I think the second example would preclude us using LDAPR for load-acquire,
    > so I'm surprised that RISC-V is ok with this. For example, the first test
    > below is allowed on arm64.
    >
    > I also think this would break if we used DMB LD to implement load-acquire
    > (second test below).
    >
    > So I'm not a big fan of this change, and I'm surprised this works on all
    > architectures. What's the justification?

    I also just realised that this prevents Power from using ctrl+isync to
    implement acquire, should they wish to do so.

    Will

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