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:   Thu, 14 Oct 2021 09:14:30 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Florian Weimer <fw@...eb.enyo.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Andrea Parri <parri.andrea@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        j alglave <j.alglave@....ac.uk>,
        luc maranget <luc.maranget@...ia.fr>,
        akiyks <akiyks@...il.com>,
        linux-toolchains <linux-toolchains@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [RFC PATCH] LKMM: Add ctrl_dep() macro for control dependency

On Wed, Oct 13, 2021 at 10:14:31PM -0400, Alan Stern wrote:
> On Wed, Oct 13, 2021 at 05:01:04PM -0700, Paul E. McKenney wrote:
> > On Sun, Oct 10, 2021 at 04:02:02PM +0200, Florian Weimer wrote:
> > > * Linus Torvalds:
> > > 
> > > > On Fri, Oct 1, 2021 at 9:26 AM Florian Weimer <fweimer@...hat.com> wrote:
> > > >>
> > > >> Will any conditional branch do, or is it necessary that it depends in
> > > >> some way on the data read?
> > > >
> > > > The condition needs to be dependent on the read.
> > > >
> > > > (Easy way to see it: if the read isn't related to the conditional or
> > > > write data/address, the read could just be delayed to after the
> > > > condition and the store had been done).
> > > 
> > > That entirely depends on how the hardware is specified to work.  And
> > > the hardware could recognize certain patterns as always producing the
> > > same condition codes, e.g., AND with zero.  Do such tests still count?
> > > It depends on what the specification says.
> > > 
> > > What I really dislike about this: Operators like & and < now have side
> > > effects, and is no longer possible to reason about arithmetic
> > > expressions in isolation.
> > 
> > Is there a reasonable syntax that might help with these issues?
> > 
> > Yes, I know, we for sure have conflicting constraints on "reasonable"
> > on copy on this email.  What else is new?  ;-)
> > 
> > I could imagine a tag of some sort on the load and store, linking the
> > operations that needed to be ordered.  You would also want that same
> > tag on any conditional operators along the way?  Or would the presence
> > of the tags on the load and store suffice?
> 
> Here's a easy cop-out.  Imagine a version of READ_ONCE that is 
> equivalent to:
> 
> 	a normal READ_ONCE on TSO architectures,
> 
> 	a load-acquire on more weakly ordered architectures.
> 
> Call it READ_ONCE_FOR_COND, for the sake of argument.  Then as long as 
> people are careful to use READ_ONCE_FOR_COND when loading the values 
> that a conditional expression depends on, and WRITE_ONCE for the 
> important stores in the branches of the "if" statement, all 
> architectures will have the desired ordering.  (In fact, if there are 
> multiple loads involved in the condition then only the last one has to 
> be READ_ONCE_FOR_COND; the others can just be READ_ONCE.)
> 
> Of course, this is not optimal on non-TSO archictecture.  That's why I 
> called it a cop-out.  But at least it is simple and easy.

That is the ARMv8 approach in CONFIG_LTO=y kernels.  ;-)

							Thanx, Paul

Powered by blists - more mailing lists