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

[Boqun Feng]

On Fri, Feb 13, 2026 at 04:58:54PM +0100, Greg KH wrote:
> 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()?
> 

I believe you hadn't read my reply that we indeed call memcpy() here. So
I'm not going to reply this in case you mean something else.

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

Well, in standard C, technically memcpy() has the same problem as Rust's
`core::ptr::copy()` and `core::ptr::copy_nonoverlapping()`, i.e. they
are vulnerable to data races. Our in-kernel memcpy() on the other hand
doesn't have this problem. Why? Because it's volatile byte-wise atomic
per the implementation.

So here, the clearing out is needed to say: this is not Rust's `copy()`
and this is not C's `memcpy()`, this is the kernel version, and it's
fine not because magic or kernel people believe it, but because its
implementation. The concept of byte-wise atomic at least describes this
correctly.

Regards,
Boqun

> thanks,
> 
> greg k-h