linux-kernel - Re: [PATCH 00/14] alpha: cleanups for 6.10

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: <alpine.DEB.2.21.2406031716490.9248@angie.orcam.me.uk>
Date: Mon, 3 Jun 2024 17:22:22 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: "Paul E. McKenney" <paulmck@...nel.org>
cc: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
    Arnd Bergmann <arnd@...nel.org>, linux-alpha@...r.kernel.org, 
    Arnd Bergmann <arnd@...db.de>, 
    Richard Henderson <richard.henderson@...aro.org>, 
    Ivan Kokshaysky <ink@...assic.park.msu.ru>, 
    Matt Turner <mattst88@...il.com>, Alexander Viro <viro@...iv.linux.org.uk>, 
    Marc Zyngier <maz@...nel.org>, 
    Linus Torvalds <torvalds@...ux-foundation.org>, 
    linux-kernel@...r.kernel.org, Michael Cree <mcree@...on.net.nz>, 
    Frank Scheiner <frank.scheiner@....de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10

On Fri, 31 May 2024, Paul E. McKenney wrote:

> >  You're the RCU expert so you know the answer.  I don't.  If it's OK for
> > successive writes to get reordered, or readers to see a stale value, then 
> > you don't need memory barriers.  Otherwise you do.  Whether byte accesses 
> > are available or not does not matter, the CPU *will* do reordering if it's 
> > allowed to (or more specifically, it won't do anything to prevent it from 
> > happening, especially in SMP configurations; I can't remember offhand if 
> > there are cases with UP).  Also adjacent byte writes may be merged, but I 
> > suppose it does not matter, or does it?
> 
> RCU uses whichever wrapper is required.  For example, if ordering is
> required, it might use smp_store_release() and smp_load_acquire().
> If ordering does not matter, it might use WRITE_ONCE() and READ_ONCE().
> If tearing/fusing/merging does not matter, as in there are not concurrent
> accesses, it uses plain C-language loads and stores.

 Fair enough.

> >  NB MIPS has similar architectural arrangements (and a bunch of barriers 
> > defined in the ISA), it's just most implementations are actually strongly 
> > ordered, so most people can't see the effects of this.  With MIPS I know 
> > for sure there are cases of UP reordering, but they only really matter for 
> > MMIO use cases and not regular memory.
> 
> Any given architecture is required to provide architecture-specific
> implementations of the various functions that meet the requirements of
> Linux-kernel memory model.  See tools/memory-model for more information.

 This is a fairly recent addition, thank you for putting it all together.  
I used to rely solely on Documentation/memory-barriers.txt.  Thanks for 
the reference.

  Maciej