Re: [PATCH v3] rust: page: add byte-wise atomic memory copy methods
From: Alice Ryhl
Date: Wed Feb 18 2026 - 07:00:51 EST
On Wed, Feb 18, 2026 at 12:57 PM Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> wrote:
>
> On Fri, Feb 13, 2026 at 7:43 AM Andreas Hindborg <a.hindborg@xxxxxxxxxx> wrote:
> >
> > @@ -282,6 +318,7 @@ pub unsafe fn read_raw(&self, dst: *mut u8, offset: usize, len: usize) -> Result
> > /// # Safety
> > ///
> > /// * Callers must ensure that `src` is valid for reading `len` bytes.
> > + /// * Callers must ensure that there are no concurrent writes to the source memory region.
> > /// * Callers must ensure that this call does not race with a read or write to the same page
> > /// that overlaps with this write.
> > pub unsafe fn write_raw(&self, src: *const u8, offset: usize, len: usize) -> Result {
>
> Coming from:
>
> https://lore.kernel.org/rust-for-linux/20260215-page-additions-v1-0-4827790a9bc4@xxxxxxxxxx/T/#md120cdea73132fc698bf69bf3d69287c2cb28449
>
> Leaving a comment here to avoid forgetting: I think the new bullet
> point here and elsewhere is not needed, i.e. the first one uses "valid
> for reads" which I think is meant to already exclude data races.
That's right, valid for reads implies that it's okay to read it.
> > + /// - For the duration of the call, other accesses to the areas described by `src` and `len`,
> > + /// must not cause data races (defined by [`LKMM`]) against atomic operations executed by this
> > + /// function. Note that if all other accesses are atomic, then this safety requirement is
> > + /// trivially fulfilled.
>
> And, for this one, Benno said perhaps we should introduce a shorthand.
valid for atomic reads?
Alice