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

[Boqun Feng <boqun@kernel.org>]

On Fri, Feb 13, 2026 at 04:34:04PM +0100, Greg KH wrote:
> On Fri, Feb 13, 2026 at 03:26:08PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 13, 2026 at 03:13:01PM +0100, Andreas Hindborg wrote:
> > 
> > > C uses memcpy as seen in `bio_copy_data_iter` [1] and in the null_blk
> > > driver [2].
> > 
> > Right. And that is *fine*.
> > 

Yes, that's fine because memcpy() in C is volatile and per-byte atomic.

> > > Rust has `core::ptr::copy` and `core::ptr::copy_nonoverlapping`. I was
> > > informed these are not safe to use if source or destination may incur
> > > data races, and that we need an operation that is volatile or byte-wise
> > > atomic [3].
> > 
> > Safe how? It should just copy N bytes. Whatever it thinks those bytes
> > are.
> > 
> > Nothing can guard against concurrent modification. If there is, you get
> > to keep the pieces. Pretending anything else is delusional.
> > 
> > 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).

> > No byte wise volatile barrier using nonsense is going to make this any
> > better.

It's byte-wise atomic [1], which should be guaranteed using asm to
implement, hence at least at byte level, they are atomic (and volatile
in our case).

[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1478r5.html

> > 
> 
> I'm with Peter, just call memcpy() like the C code does, and you will be
> "fine" (with a note that "fine" better include checking the data really

We are. See v3, we actually use `memcpy()` for the copy (as I already
pointed out, Andreas made a mistake in this version), it's just
because it's per-byte atomic. What this "byte-wise atomic" does is
clearing things out.

Regards,
Boqun

> is what you think it is if you are going to do anything based on it and
> not just pass it off to the hardware.)
> 
> thanks,
> 
> greg k-h