Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Date:   Mon, 6 Nov 2023 00:08:59 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     j.alglave@ucl.ac.uk, will@kernel.org, catalin.marinas@arm.com,
        linux@armlinux.org.uk, mpe@ellerman.id.au, npiggin@gmail.com,
        palmer@dabbelt.com, parri.andrea@gmail.com,
        linux-kernel@vger.kernel.org, linux-toolchains@vger.kernel.org,
        boqun.feng@gmail.com, davidtgoldblatt@gmail.com
Subject: Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load)
 discussion
Message-ID: <20231105230859.GH8262@noisy.programming.kicks-ass.net>
References: <b1634b24-4541-49c5-867c-7f24292a27bb@paulmck-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b1634b24-4541-49c5-867c-7f24292a27bb@paulmck-laptop>
Precedence: bulk

On Fri, Oct 27, 2023 at 02:08:13PM -0700, Paul E. McKenney wrote:
> Hello!
> 
> FYI, unless someone complains, it is quite likely that C++ (and thus
> likely C) compilers and standards will enforce Hans Boehm's proposal
> for ordering relaxed loads before relaxed stores.  The document [1]
> cites "Bounding data races in space and time" by Dolan et al. [2], and
> notes an "average a 2.x% slow down" for ARMv8 and PowerPC.  In the past,
> this has been considered unacceptable, among other things, due to the
> fact that this issue is strictly theoretical.
> 
> This would not (repeat, not) affect the current Linux kernel, which
> relies on volatile loads and stores rather than C/C++ atomics.
> 
> To be clear, the initial proposal is not to change the standards, but
> rather to add a command-line argument to enforce the stronger ordering.
> However, given the long list of ARM-related folks in the Acknowledgments
> section, the future direction is clear.
> 
> So, do any ARMv8, PowerPC, or RISC-V people still care?  If so, I strongly
> recommend speaking up.  ;-)

OK, I finally had some time to read up...

Colour me properly confused. To me this all reads like C people can't
deal with relaxed atomics and are doing crazy things to try and 'fix'
it.

And while I don't speak for ARM/Power, I do worry this all takes C/C++
even further away from LKMM instead of closing the gap.

Worse, things like:

  https://lukegeeson.com/blog/2023-10-17-A-Proposal-For-Relaxed-Atomics/

Which state:

 "It would solve real issues in the Linux Kernel without costly fences
 (the kernel does not use relaxed atomics or the ISO C/C++ model - the
 load buffering issue affects the ISO C and linux memory models) ..."

Which is a contradiction if ever I saw one. It both claims this atrocity
fixes our volatile_if() woes while at the same time saying we're
unaffected because we don't use any of the C/C++ atomic batshit.

Anyway, I worry that all this faffing about will get in the way of our
volatile_if() 'demands'. Compiler people will tell us, just use relaxed
atomics, which that is very much not what we want. We know relaxed loads
and stores behave 'funny', we've been doing that for a long long time.
Don't impose that madness on us. And certainly don't use us as an excuse
to peddle this nonsense.

Bah, what a load of crazy.

/me stomps off in disgust.