Re: [RFC] rust: types: Add read_once and write_once

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Oct 25, 2023 at 12:53:39PM -0700, Boqun Feng wrote:
> In theory, `read_volatile` and `write_volatile` in Rust can have UB in
> case of the data races [1]. However, kernel uses volatiles to implement
> READ_ONCE() and WRITE_ONCE(), and expects races on these marked accesses
> don't cause UB. And they are proven to have a lot of usages in kernel.
> 
> To close this gap, `read_once` and `write_once` are introduced, they
> have the same semantics as `READ_ONCE` and `WRITE_ONCE` especially
> regarding data races under the assumption that `read_volatile` and
> `write_volatile` have the same behavior as a volatile pointer in C from
> a compiler point of view.
> 
> Longer term solution is to work with Rust language side for a better way
> to implement `read_once` and `write_once`. But so far, it should be good
> enough.

So the whole READ_ONCE()/WRITE_ONCE() thing does two things we care
about (AFAIR):

 - single-copy-atomicy; this can also be achieved using the C11
   __atomic_load_n(.memorder=__ATOMIC_RELAXED) /
   __atomic_store_n(.memorder=__ATOMIC_RELAXED) thingies.

 - the ONCE thing; that is inhibits re-materialization, and here I'm not
   sure C11 atomics help, they might since re-reading an atomic is
   definitely dodgy -- after all it could've changed.

Now, traditionally we've relied on the whole volatile thing simply
because there was no C11, or our oldest compiler didn't do C11. But
these days we actually *could*.

Now, obviously C11 has issues vs LKMM, but perhaps the load/store
semantics are near enough to be useful.  (IIRC this also came up in the
*very* long x86/percpu thread)

So is there any distinction between the volatile load/store and the C11
atomic load/store that we care about and could not Rust use the atomic
load/store to avoid their UB ?