Message-ID: <aX4tTMrMx1G7hXHf@tardis.local>
Date: Sat, 31 Jan 2026 08:26:52 -0800
From: Boqun Feng <boqun@...nel.org>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: 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>, 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 Sat, Jan 31, 2026 at 02:34:02PM +0100, Andreas Hindborg wrote:
[..]
> >
> > For DMA memory, it can be almost treated as external normal memory,
> > however, different archictures/systems/platforms may have different
> > requirement regarding cache coherent between CPU and devices, specially
> > mapping or special instructions may be needed.
> 
> Cache flushing and barriers, got it.
> 

For completeness, I think for some architectures/platforms, cache
coherence between CPU and devices can be achieved by hardware, in that
case, DMA memory access can be just a normal memory access.

> >
> > For __user memory, because kernel is only given a userspace address, and
> > userspace can lie or unmap the address while kernel accessing it,
> > copy_{from,to}_user() is needed to handle page faults.
> 
> Just to clarify, for my use case, the page is already mapped to kernel
> space, and it is guaranteed to be mapped for the duration of the call
> where I do the copy. Also, it _may_ be a user page, but it might not
> always be the case.
> 

Ok, if it's not a page mapped to userspace, would there be any other
access from kernel while copying the page? If there is other kernel
thread or interrupt could write to source page, the write needs to be
atomic in some level (byte-wise for example), so does the read part of
the copy.

> >
> > Your use case (copying between userspace-mapped memory and kernel
> > memory) is, as Gary said, the least special here. So using
> > memcpy_{from,to}io() would be overkill and probably misleading.
> 
> Ok, I understand.
> 
> > I
> > suggest we use `{read,write}_volatile()` (unless I'm missing something
> > subtle of course), however `{read,write}_volatile()` only works on Sized
> > types,
> 
> We can copy as u8? Or would it be more efficient to copy as a larger size?
> 

Copying as a larger size is more efficient: less instructions for the
same amount of data to copy.

> You suggested atomic in the other email, did you abandon that idea?
> 

No, if we have byte-wise atomic copy, I'd still use that, but that is
not something already implemented in Rust. (my reply had a "if we want
to avoid implementing something by ourselves" at last)

> > so we may have to use `bindings::memcpy()` or
> > core::intrinsics::volatile_copy_memory() [1]
> 
> I was looking at this one, but it is unstable behind `core_intrinsics`.
> I was uncertain about pulling in additional unstable features. This is

That's also why I said "(or suggest Rust to stabilize something).

> why I was looking for something in the C kernel to use.
> 
> I think `bindings::memcpy` is not guaranteed to be implemented as inline
> assembly, so it may not have volatile semantics?
> 

Well, it's used in C as if it's volatile, for example, it's used in the
similar case in bio_copy_data_iter() (hopefully you can confirm that's
indeed a similar case). And I'm suggesting we use it forever, just use
it while waiting for volatile_copy_memory() or something.

Regards,
Boqun

> 
> Best regards,
> Andreas Hindborg
> 
> 
> 

Powered by blists - more mailing lists