Message-Id: <DG21IW5HZV2F.PXTH9P2IO8O7@garyguo.net>
Date: Fri, 30 Jan 2026 15:48:26 +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 3:23 PM GMT, Andreas Hindborg wrote:
> "Gary Guo" <gary@...yguo.net> writes:
>
>> 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.
>
> I would treat them the same as DMA regions and MMIO regions. As these
> regions are outside of any Rust allocation, if we never make references
> to them and if we only operate on them with volatile operations,
> behavior of the copy operations like these are defined, as far as I
> understand.

I don't find the argument about these being outside Rust allocation very useful.
Apart from MMIO, I view all other types of memory still within purview of the
abstract machine.

>
> In the last discussions we had on this, the conclusion was to use
> `volatile_copy_memory` whenever that is available, or write a volatile
> copy function in assembly.
>
> Using memcpy_{from,to}io is the latter solution. These functions are
> simply volatile memcpy implemented in assembly.
>
> There is nothing special about MMIO. These functions are name as they
> are because they are useful for MMIO.

No. MMIO are really special. A few architectures require them to be accessed
completely differently compared to normal memory. We also have things like
INDIRECT_IOMEM. memory_{from,to}io are special as they use MMIO accessor such as
readb to perform access on the __iomem pointer. They should not be mixed with
normal memory. They must be treated as if they're from a completely separate
address space.

Normal memory vs DMA vs MMIO are all distinct, and this is demonstrated by the
different types of barriers needed to order things correctly for each type of
memory region.

Userspace-mapped memory (that is also mapped in the kernel space, not __user) is
the least special one out of these. They could practically share all atomic infra
available for the kernel, hence the suggestion of using byte-wise atomic memcpy.

Best,
Gary

>
>
> Best regards,
> Andreas Hindborg

Powered by blists - more mailing lists