[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DG1Y5V810II1.1HE2T0HDBLNXI@garyguo.net>
Date: Fri, 30 Jan 2026 13:10:22 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Andreas Hindborg" <a.hindborg@...nel.org>, "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>, "Gary Guo"
<gary@...yguo.net>, 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 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.
Best,
Gary
> + Ok(())
> + })
> + }
> +
> /// Maps the page and writes into it from the given buffer.
> ///
> /// This method will perform bounds checks on the page offset. If `offset .. offset+len` goes
> @@ -282,6 +309,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 {
> @@ -295,6 +323,31 @@ pub unsafe fn write_raw(&self, src: *const u8, offset: usize, len: usize) -> Res
> })
> }
>
> + /// Maps the page and writes into it from 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 source memory region is outside of any Rust memory allocation.
> + /// * The source memory region is readable.
> + /// * This call does not race with a read or write to the same destination page that overlaps
> + /// with this write.
> + pub unsafe fn write_raw_fromio(&self, src: *const u8, offset: usize, len: usize) -> Result {
> + self.with_pointer_into_page(offset, len, move |dst| {
> + // SAFETY: If `with_pointer_into_page` calls into this closure, then it has performed a
> + // bounds check and guarantees that `dst` is valid for `len` bytes.
> + //
> + // There caller guarantees that there is no data race at the destination.
> + unsafe { bindings::memcpy_fromio(dst.cast::<c_void>(), src.cast::<c_void>(), len) };
> + Ok(())
> + })
> + }
> +
> /// Maps the page and zeroes the given slice.
> ///
> /// This method will perform bounds checks on the page offset. If `offset .. offset+len` goes
>
> ---
> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
> change-id: 20260130-page-volatile-io-05ff595507d3
>
> Best regards,
Powered by blists - more mailing lists