Re: [RFC] LKMM: Add volatile_if()
From: "Paul E. McKenney" <paulmck@kernel.org>
Date: 2021-06-04 20:56:02
Also in:
linux-arch, lkml
On Fri, Jun 04, 2021 at 12:18:43PM -0700, Linus Torvalds wrote:
On Fri, Jun 4, 2021 at 12:09 PM Linus Torvalds [off-list ref] wrote:quoted
Again, semantics do matter, and I don't see how the compiler could actually break the fundamental issue of "load->conditional->store is a fundamental ordering even without memory barriers because of basic causality", because you can't just arbitrarily generate speculative stores that would be visible to others.This, after all, is why we trust that the *hardware* can't do it. Even if the hardware mis-speculates and goes down the wrong branch, and speculatively does the store when it shouldn't have, we don't care: we know that such a speculative store can not possibly become semantically visible (*) to other threads. For all the same reasons, I don't see how a compiler can violate causal ordering of the code (assuming, again, that the test is _meaningful_ - if we write nonsensical code, that's a different issue).
I am probably missing your point, but something like this: if (READ_ONCE(x)) y = 42; else y = 1729; Can in theory be transformed into something like this: y = 1729; if (READ_ONCE(x)) y = 42; The usual way to prevent it is to use WRITE_ONCE(). Fortunately, register sets are large, and gcc manages to do a single store and use only %eax. Thanx, Paul
If we have compilers that create speculative stores that are visible
to other threads, we need to fix them.
Linus
(*) By "semantically visible" I intend to avoid the whole timing/cache
pattern kind of non-semantic visibility that is all about the spectre
leakage kind of things.