[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877bszrz37.fsf@t14s.mail-host-address-is-not-set>
Date: Fri, 30 Jan 2026 14:48:12 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: 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>, 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
"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]:
/// Copy data to the current page of this segment from `src_page`.
///
/// Copies `PAGE_SIZE - (self.offset() % PAGE_SIZE` bytes of data from `src_page` to this
/// segment starting at `self.offset()` from offset `self.offset() % PAGE_SIZE`. This call
/// will advance offset and reduce length of `self`.
///
/// Returns the number of bytes copied.
pub fn copy_from_page(&mut self, src_page: &Page, src_offset: usize) -> usize {
let dst_offset = self.offset() % PAGE_SIZE;
debug_assert!(src_offset <= PAGE_SIZE);
let length = (PAGE_SIZE - dst_offset)
.min(self.len() as usize)
.min(PAGE_SIZE - src_offset);
let page_idx = self.offset() / PAGE_SIZE;
// SAFETY: self.bio_vec is valid and thus bv_page must be a valid
// pointer to a `struct page`.
let dst_page = unsafe { Page::from_raw(self.bio_vec.bv_page.add(page_idx)) };
dst_page
.with_pointer_into_page(dst_offset, length, |dst| {
// SAFETY:
// - If `with_pointer_into_page` calls this closure, then it has performed bounds
// checks and guarantees that `dst` is valid for `length` bytes.
// - Since we have a shared reference to `src_page`, the read cannot race with any
// writes to `src_page`.
unsafe { src_page.read_raw_toio(dst, src_offset, length) }
})
.expect("Assertion failure, bounds check failed.");
self.advance(length as u32)
.expect("Assertion failure, bounds check failed.");
length
Best regards,
Andreas Hindborg
[1] https://github.com/metaspace/linux/blob/3e46e95f0707fa71259b1d241f689144ad61cc62/rust/kernel/block/bio/vec.rs#L142
Powered by blists - more mailing lists