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

[Andreas Hindborg]

"Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> writes:

> On Fri, Feb 13, 2026 at 01:58:16PM +0100, Andreas Hindborg wrote:
>> "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
>>
>> > On Fri, Feb 13, 2026 at 10:55:57AM +0100, Peter Zijlstra wrote:
>> >> On Thu, Feb 12, 2026 at 03:51:24PM +0100, Andreas Hindborg wrote:
>> >> > When copying data from buffers that are mapped to user space, it is
>> >> > impossible to guarantee absence of concurrent memory operations on those
>> >> > buffers. Copying data to/from `Page` from/to these buffers would be
>> >> > undefined behavior if no special considerations are made.
>> >> >
>> >> > Add methods on `Page` to read and write the contents using byte-wise atomic
>> >> > operations.
>> >>
>> >> I'm completely failing to understand. What!?
>> >>
>> >> There is no such thing as an 'atomic' byte load, nor does it help one
>> >> whit against concurrent modification of the memory you're copying.
>> >
>> > I too am totally confused when reading this patch, and the previous
>> > ones.  Shouldn't the "normal" copy_from_user() stuff be used here
>> > correctly?  Why is anything new needed?
>>
>> One use for this is copying data out of a `struct bio_vec`. As far as I
>> know, there is no way to know where the pages backing a bio_vec are
>> mapped. They could be mapped to user space.
>
> And how does C code do this today?  Surely there's a function that is
> used there that we should also be using here, right?  Why do we need
> something different?

C uses memcpy as seen in `bio_copy_data_iter` [1] and in the null_blk
driver [2].

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

Thus, we build an abstraction relying on byte-wise atomicity that does
not race under LKMM.

Best regards,
Andreas Hindborg

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/bio.c?h=v6.19#n1458
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/null_blk/main.c?h=v6.19#n1162
[3] https://lore.kernel.org/r/aYFKbWfQmTInYy91@tardis.local