Message-Id: <DG20LKAHMXMZ.262Y7NAC1A1Z9@garyguo.net>
Date: Fri, 30 Jan 2026 15:04:54 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Andreas Hindborg" <a.hindborg@...nel.org>, "Gary Guo"
 <gary@...yguo.net>, "Alice Ryhl" <aliceryhl@...gle.com>, "Lorenzo Stoakes"
 <lorenzo.stoakes@...cle.com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 "Miguel Ojeda" <ojeda@...nel.org>, "Boqun Feng" <boqun.feng@...il.com>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Benno Lossin"
 <lossin@...nel.org>, "Trevor Gross" <tmgross@...ch.edu>, "Danilo Krummrich"
 <dakr@...nel.org>
Cc: <linux-mm@...ck.org>, <rust-for-linux@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rust: page: add volatile memory copy methods

On Fri Jan 30, 2026 at 2:42 PM GMT, Andreas Hindborg wrote:
> "Gary Guo" <gary@...yguo.net> writes:
>
>> On Fri Jan 30, 2026 at 1:48 PM GMT, Andreas Hindborg wrote:
>>> "Gary Guo" <gary@...yguo.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@...nel.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?

Memory that is possibly mapped into userspace is still normal memory, it is not
I/O. I/O accessors (and IO memcpy) are specifically used for MMIO, and you
should not be using them for userspace memory.

For memory that can be mutated from userspace you can just treat them as a
potentially concurrent accessor hence all accesses should be using atomic. When
tearing is acceptable, byte-wise atomic is sufficient.

Best,
Gary

>
>
> Best regards,
> Andreas Hindborg

Powered by blists - more mailing lists