volatile [LWN.net]

volatile

Posted Oct 7, 2021 10:45 UTC (Thu) by tialaramex (subscriber, #21167)
In reply to: volatile by PaulMcKenney
Parent article: McKenney: So You Want to Rust the Linux Kernel?

Can you say a bit more, or a bit more concretely, than "some architectures" and "some cases" where this cheap-looking feature might actually be arbitrarily more complicated and need wrapping?

to post comments

volatile

Posted Oct 7, 2021 16:06 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (2 responses)

DEC Alpha needs a full memory-barrier instruction after the load emitted by READ_ONCE().

Itanium needs a READ_ONCE() to emit an acquire-load instruction and a WRITE_ONCE() to emit a store-release instruction, but the C compiler takes care of that for us. Plus it is not obvious that Rust would ever need to care about this particular case.

ARMv8 needs a READ_ONCE() to emit an acquire-load instruction, but only in kernel builds that enable LTO, that is, builds that have CONFIG_LTO or similar enabled. (This choice stems from concerns that LTO breaks address, data, and/or control dependencies.)

So not massively complex, but something that needs to be kept track of.

volatile

Posted Oct 8, 2021 19:24 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (1 responses)

So, if I'm not misunderstanding you need acquire-release semantics (you don't need to ask for them on x86 because x86 always has acquire-release semantics), that's what all of these cases seem to be doing.

Because x86 doesn't care, I don't actually know and it wouldn't surprise me if the existing volatile intrinsics already have acquire-release on every platform. But even if not it does still feel like this makes more sense as a (new) intrinsic than trying to call into C every time.

volatile

Posted Oct 8, 2021 20:09 UTC (Fri) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Why not take a look at the actual Rust documentation and implementation to see what the Rust volatile intrinsics actually guarantee across architectures?