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

[Gary Guo]

On 2026-02-13 15:34, 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*.
>> 
>> > 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.
>> 
>> No byte wise volatile barrier using nonsense is going to make this any
>> better.
>> 
> 
> 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
> 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.)

As Boqun already pointed out in other thread, this *is* the direction that we're
heading for. We're not going to add a new implementation, just to add an API
with documented semantics which is distinct from existing Rsut
"copy_nonoverlapping", which in many cases is lowered to memcpy, but does not
have the correct semantics, as it is a compiler builtin, so compiler can
optimize on it and understand it as non-atomic non-volatile operation.

BTW, note that calling "memcpy" from C side doesn't actually have the right
semantics, as C, unlike Rust where compiler builtins are explicit, recognize
them by function names. So if you write "memcpy" without adding `-fno-builtin`
(or `-fno-builtin-memcpy`) flag, it *is* recognized by compiler as a normal,
non-atomic and non-volatile memcpy. The compiler is free to turn it to something
that is not an actual function call to "memcpy". It happens that when doing BIO
and copying a page, this is large enough that compilers always defer to actual
"memcpy" implementation, but this is another case that "it works in practice".

Best,
Gary

> 
> thanks,
> 
> greg k-h