Re: [PATCH v2] rust: page: add byte-wise atomic memory copy methods

[Alice Ryhl <aliceryhl@google.com>]

On Tue, Feb 17, 2026 at 10:23:43AM +0100, Peter Zijlstra wrote:
> On Tue, Feb 17, 2026 at 10:17:23AM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 13, 2026 at 07:45:19AM -0800, Boqun Feng wrote:
> > 
> > > > > Suppose the memory was 'AAAA' and while you're reading it, it is written
> > > > > to be 'BBBB'. The resulting copy can be any combination of
> > > > > '[AB][AB][AB][AB]'. Not one of them is better than the other.
> > > > > 
> > > 
> > > The idea is if using Rust's own `core::ptr::copy()` or
> > > `core::ptr::copy_nonoverlapping()`, you may get `CCCC`, because they are
> > > not semantically guaranteed atomic per byte (i.e. tearing can happen at
> > > bit level, because they are not designed for using in case of data
> > > races, and there is no defined asm implementation of them, compilers can
> > > do anything).
> > 
> > How the heck would they do out-of-thin-air? Any memcpy() implementation
> > that can cause that is insane and broken.
> > 
> > Compilers are broken crap if they do this.
> 
> If rust core code can cause this, I stand by my earlier position that we
> should not want that anywhere near the kernel. There is a reason our C
> code is free standing.
> 
> So fix Rust to not be broken or take it out.

It can cause this to exactly the same extent as C can, and that's why
you all came up with READ_ONCE() and similar.

Rust's copy_nonoverlapping() might not call memcpy() if it's a small
fixed amount of bytes. E.g. a copy_nonoverlapping() of 8 bytes might
just emit a movq instruction or any other way the compiler can come up
with to copy 8 bytes. Like C compilers, that includes emitting more than
one read, for the same reasons as why C might emit multiple reads for a
single read when READ_ONCE() is not used.

After all, this logic all comes from LLVM which clang and rustc share.

Alice