linux-kernel - Re: Unlock-lock questions and the Linux Kernel Memory Model

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]

Message-ID: <Pine.LNX.4.44L0.1711301247460.1380-100000@iolanthe.rowland.org>
Date:   Thu, 30 Nov 2017 12:56:55 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:     Will Deacon <will.deacon@....com>,
        Daniel Lustig <dlustig@...dia.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrea Parri <parri.andrea@...il.com>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Jade Alglave <j.alglave@....ac.uk>,
        Boqun Feng <boqun.feng@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Unlock-lock questions and the Linux Kernel Memory Model

On Thu, 30 Nov 2017, Paul E. McKenney wrote:

> > > Will, are there plans to bring this sort of thing before the standards
> > > committee?
> > 
> > We discussed it, but rejected it mainly because of concerns that there could
> > be RmW operations that don't necessarily have an order-inducing dependency
> > in all scenarios. I think the case that was batted around was a saturating
> > add implemented using cmpxchg.
> 
> Ah, I do remember now, during the Toronto meeting, correct?
> 
> So should we consider making LKMM make xchg act in a manner similar to
> the other atomics, or would you prefer that we keep the current special
> behavior?

In fact, right now herd doesn't implement the dependencies.  So
"current special behavior" is ambiguous -- there's what herd currently
does, and there's what one would expect it to do.

(Incidentally, this should all be considered part of herd, rather than
part of the LKMM.  Although herd can simulate the memory model, they 
aren't the same thing.)

Also, as Will says, some atomic operations have more than one possible
implementation, with differing internal dependencies.

Alan