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

[Boqun Feng <boqun.feng@gmail.com>]

On Wed, Oct 25, 2023 at 04:02:45PM -0700, Boqun Feng wrote:
[...]
> > > +/// The counter part of C `READ_ONCE()`.
> > > +///
> > > +/// The semantics is exactly the same as `READ_ONCE()`, especially when used for intentional data
> > > +/// races.
> > 
> > It would be great if these semantics are either linked or spelled out
> > here. Ideally both.
> > 
> 
> Actually I haven't found any document about `READ_ONCE()` races with
> writes is not UB: we do have document saying `READ_ONCE()` will disable
> KCSAN checks, but no document says (explicitly) that it's not a UB.
> 

Apparently I wasn't carefully reading the doc, in
tools/memory-model/Documentation/explanation.txt, there is:

	In technical terms, the compiler is allowed to assume that when the
	program executes, there will not be any data races.  A "data race"
	occurs when there are two memory accesses such that:

	1.      they access the same location,

	2.      at least one of them is a store,

	3.      at least one of them is plain,

	4.      they occur on different CPUs (or in different threads on the
		same CPU), and

	5.      they execute concurrently.

the #3 limits that in LKMM, data races cannot happen if both accesses
are marked (i.e. not plain).

Thank Paul for bringing this to me, and I will update this accordingly
in the next version.

Regards,
Boqun

> > > +///
> > > +/// # Safety
> > > +///
> > > +/// * `src` must be valid for reads.
> > > +/// * `src` must be properly aligned.
> > > +/// * `src` must point to a properly initialized value of value `T`.
> > > +#[inline(always)]
> > > +pub unsafe fn read_once<T: Copy>(src: *const T) -> T {
> > 
> > Why only `T: Copy`?
> > 
[...]