Messages in this thread | | | Date | Fri, 4 Jun 2021 13:56:00 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [RFC] LKMM: Add volatile_if() |
| |
On Fri, Jun 04, 2021 at 12:18:43PM -0700, Linus Torvalds wrote: > On Fri, Jun 4, 2021 at 12:09 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > 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.
| |