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

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Feb 13, 2026 at 07:45:19AM -0800, Boqun Feng wrote:
> 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).

Then why not just call the proper, in-kernel, arch specific, patched and
tested to the end-of-the-earth, memcpy()?

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

Again, just use memcpy() please.

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

clear what out?  It shouldn't need anything special for a memcpy.

thanks,

greg k-h