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 :/