Re: [RFC] LKMM: Add volatile_if()

Peter Zijlstra
2021-06-07T10:43:19Z

On Sun, Jun 06, 2021 at 11:43:42AM -0700, Linus Torvalds wrote:
> So while the example code is insane and pointless (and you shouldn't
> read *too* much into it), conceptually the notion of that pattern of
>
> if (READ_ONCE(a)) {
> WRITE_ONCE(b,1);
> .. do something ..
> } else {
> WRITE_ONCE(b,1);
> .. do something else ..
> }

This is actually more tricky than it would appear (isn't it always).

The thing is, that normally we must avoid speculative stores, because
they'll result in out-of-thin-air values.

*Except* in this case, where both branches emit the same store, then
it's a given that the store will happen and it will not be OOTA.
Someone's actually done the proof for that apparently (Will, you have a
reference to Jade's paper?)

There's apparently also a competition going on who can build the
weakestest ARM64 implementation ever.

Combine the two, and you'll get a CPU that *will* emit the store early
:/

So it might be prudent to make this pattern as difficult as possible (a
compiler implementation of volatile_if might be able to observe and WARN
about this).

How's something like (leaving the improved barrier() aside for now):

#define volatile_if(x) \
if (!(({ _Bool __x = (x); BUILD_BUG_ON(__builtin_constant_p(__x)); __x; }) && \
({ barrier(); 1; }))) { } else

That makes writing:

volatile_if(READ_ONCE(a)) {
WRITE_ONCE(b, 1);
// something
} else {
WRITE_ONCE(b, 1);
// something else
}

A syntax error, due to volatile_if() already being an else. And yes,
there's plenty other ways to write the same :/