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

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Feb 17, 2026 at 09:37:46AM +0000, Alice Ryhl wrote:
> 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.

So READ_ONCE() was mostly about inhibiting the compiler from re-loading
the value. We later added the no-tearing thing.

> 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.

Right, compiler is allowed to write code instead of emit memcpy() call.
But that code had better not be silly.

And since the C thing isn't silly, why would the Rust thing be silly?