Re: [PATCH] rust: page: add volatile memory copy methods

[Andreas Hindborg <a.hindborg@kernel.org>]

"Gary Guo" <gary@garyguo.net> writes:

> On Fri Jan 30, 2026 at 1:48 PM GMT, Andreas Hindborg wrote:
>> "Gary Guo" <gary@garyguo.net> writes:
>>
>>> On Fri Jan 30, 2026 at 12:33 PM GMT, Andreas Hindborg wrote:
>>>> When copying data from buffers that are mapped to user space, or from
>>>> buffers that are used for dma, 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 regular memcpy
>>>> operations are used.
>>>>
>>>> The operation can be made well defined, if the buffers that potentially
>>>> observe racy operations can be said to exist outside of any Rust
>>>> allocation. For this to be true, the kernel must only interact with the
>>>> buffers using raw volatile reads and writes.
>>>>
>>>> Add methods on `Page` to read and write the contents using volatile
>>>> operations.
>>>>
>>>> Also improve clarity by specifying additional requirements on
>>>> `read_raw`/`write_raw` methods regarding concurrent operations on involved
>>>> buffers.
>>>>
>>>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>>>> ---
>>>>  rust/kernel/page.rs | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 53 insertions(+)
>>>>
>>>> diff --git a/rust/kernel/page.rs b/rust/kernel/page.rs
>>>> index 432fc0297d4a8..6568a0d3b3baa 100644
>>>> --- a/rust/kernel/page.rs
>>>> +++ b/rust/kernel/page.rs
>>>> @@ -7,6 +7,7 @@
>>>>      bindings,
>>>>      error::code::*,
>>>>      error::Result,
>>>> +    ffi::c_void,
>>>>      uaccess::UserSliceReader,
>>>>  };
>>>>  use core::{
>>>> @@ -260,6 +261,8 @@ fn with_pointer_into_page<T>(
>>>>      /// # Safety
>>>>      ///
>>>>      /// * Callers must ensure that `dst` is valid for writing `len` bytes.
>>>> +    /// * Callers must ensure that there are no other concurrent reads or writes to/from the
>>>> +    ///   destination memory region.
>>>>      /// * Callers must ensure that this call does not race with a write to the same page that
>>>>      ///   overlaps with this read.
>>>>      pub unsafe fn read_raw(&self, dst: *mut u8, offset: usize, len: usize) -> Result {
>>>> @@ -274,6 +277,30 @@ pub unsafe fn read_raw(&self, dst: *mut u8, offset: usize, len: usize) -> Result
>>>>          })
>>>>      }
>>>>
>>>> +    /// Maps the page and reads from it into the given IO memory region using volatile memory
>>>> +    /// operations.
>>>> +    ///
>>>> +    /// This method will perform bounds checks on the page offset. If `offset .. offset+len` goes
>>>> +    /// outside of the page, then this call returns [`EINVAL`].
>>>> +    ///
>>>> +    /// # Safety
>>>> +    /// Callers must ensure that:
>>>> +    ///
>>>> +    /// * The destination memory region is outside of any Rust memory allocation.
>>>> +    /// * The destination memory region is writable.
>>>> +    /// * This call does not race with a write to the same source page that overlaps with this read.
>>>> +    pub unsafe fn read_raw_toio(&self, dst: *mut u8, offset: usize, len: usize) -> Result {
>>>> +        self.with_pointer_into_page(offset, len, move |src| {
>>>> +            // SAFETY: If `with_pointer_into_page` calls into this closure, then
>>>> +            // it has performed a bounds check and guarantees that `src` is
>>>> +            // valid for `len` bytes.
>>>> +            //
>>>> +            // There caller guarantees that there is no data race at the source.
>>>> +            unsafe { bindings::memcpy_toio(dst.cast::<c_void>(), src.cast::<c_void>(), len) };
>>>
>>> I feel that this should be a generic utility that integrates with our IO infra
>>> that allows you to copy/from IO to a slice.
>>
>> While that might also be useful, for my particular use case I am copying
>> between two pages. One is mapped from user space, the other one is
>> allocated by a driver. No slices involved. Pasting for reference [1]:
>
> Then what you need is a byte-wise atomic memcpy, not memcpy_{from,to}io.

Can you elaborate on how you get to this requirement?


Best regards,
Andreas Hindborg