linux-kernel - Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus test)

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 25 Jan 2023 13:23:28 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
Cc:     Andrea Parri <parri.andrea@...il.com>,
        Alan Stern <stern@...land.harvard.edu>,
        Jonas Oberhauser <jonas.oberhauser@...wei.com>,
        Peter Zijlstra <peterz@...radead.org>, will <will@...nel.org>,
        "boqun.feng" <boqun.feng@...il.com>, npiggin <npiggin@...il.com>,
        dhowells <dhowells@...hat.com>,
        "j.alglave" <j.alglave@....ac.uk>,
        "luc.maranget" <luc.maranget@...ia.fr>, akiyks <akiyks@...il.com>,
        dlustig <dlustig@...dia.com>, joel <joel@...lfernandes.org>,
        urezki <urezki@...il.com>,
        quic_neeraju <quic_neeraju@...cinc.com>,
        frederic <frederic@...nel.org>,
        Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus
 test)

On Wed, Jan 25, 2023 at 10:10:32PM +0100, Jonas Oberhauser wrote:
> 
> 
> On 1/25/2023 9:36 PM, Andrea Parri wrote:
> > > > Why do you want the implementation to forbid it?  The pattern of the
> > > > litmus test resembles 3+3W, and you don't care whether the kernel allows
> > > > that pattern.  Do you?
> > > Jonas asked a similar question, so I am answering you both here.
> > > 
> > > With (say) a release-WRITE_ONCE() chain implementing N+2W for some
> > > N, it is reasonably well known that you don't get ordering, hardware
> > > support otwithstanding.  After all, none of the Linux kernel, C, and C++
> > > memory models make that guarantee.  In addition, the non-RCU barriers
> > > and accesses that you can use to create N+2W have been in very wide use
> > > for a very long time.
> > > 
> > > Although RCU has been in use for almost as long as those non-RCU barriers,
> > > it has not been in wide use for anywhere near that long.  So I cannot
> > > be so confident in ruling out some N+2W use case for RCU.
> > Did some archeology...  the pattern, with either RCU sync plus a release
> > or with two full fences plus a release, was forbidden by "ancient LKMM":
> > the relevant changes were described in
> > 
> >    https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/WeakModel.html#Coherence%20Point%20and%20RCU
> > 
> >    Andrea
> 
> Fascinating! It says there "But the weak model allows it, as required" --
> what does "as required" mean? Just "as required by dropping the constraint"?

"As required by our reluctance to support it, given that all use cases
we have seen are traps for the unwary."

> Is there still a notion of "strong model" and "weak model", or was the
> strong model dropped?

The strong model was dropped.  The differences between them were
eventually small enough that it did not make sense to maintain two models.

							Thanx, Paul