linux-kernel - Re: "Verifying and Optimizing Compact NUMA-Aware Locks on Weak Memory Models"

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: <YwpJ4ZPVbuCnnFKS@boqun-archlinux>
Date:   Sat, 27 Aug 2022 09:44:17 -0700
From:   Boqun Feng <boqun.feng@...il.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>, parri.andrea@...il.com,
        will@...nel.org, npiggin@...il.com, dhowells@...hat.com,
        j.alglave@....ac.uk, luc.maranget@...ia.fr, akiyks@...il.com,
        dlustig@...dia.com, joel@...lfernandes.org,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: "Verifying and Optimizing Compact NUMA-Aware Locks on Weak
 Memory Models"

On Sat, Aug 27, 2022 at 12:05:33PM -0400, Alan Stern wrote:
> On Sat, Aug 27, 2022 at 01:47:48AM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 26, 2022 at 01:10:39PM -0400, Alan Stern wrote:
> > 
> > > >  - some babbling about a missing propagation -- ISTR Linux if stuffed
> > > >    full of them, specifically we require stores to auto propagate
> > > >    without help from barriers
> > > 
> > > Not a missing propagation; a late one.
> > > 
> > > Don't understand what you mean by "auto propagate without help from 
> > > barriers".
> > 
> > Linux hard relies on:
> > 
> > 	CPU0				CPU1
> > 
> > 	WRITE_ONCE(foo, 1);		while (!READ_ONCE(foo));
> > 
> > making forward progress.
> 
> Indeed yes.  As far as I can tell, this requirement is not explicitly 
> mentioned in the LKMM, although it certainly is implicit.  I can't even 
> think of a way to express it in a form Herd could verify.
> 

FWIW, C++ defines this as (in https://eel.is/c++draft/atomics#order-11):

	Implementations should make atomic stores visible to atomic
	loads within a reasonable amount of time.

in other words:

if one thread does an atomic store, then all other threads must see that
store eventually.

(from: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Rust.20forward.20progress.20guarantees/near/294702950)

Should we add something somewhere in our model, maybe in the
explanation.txt?

Plus, I think we cannot express this in Herd because Herd uses
graph-based model (axiomatic model) instead of an operational model to
describe the model: axiomatic model cannot describe "something will
eventually happen". There was also some discussion in the zulip steam
of Rust unsafe-code-guidelines.

Regards,
Boqun

> > There were a few 'funny' uarchs that were broken, see for example commit
> > a30718868915f.
> 
> Ha!  That commit should be a lesson in something, although I'm not sure 
> what.  :-)
> 
> Alan