Message-ID: <aX5YWdBxPmPrTLDA@tardis.local>
Date: Sat, 31 Jan 2026 11:30:33 -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 08:10:21PM +0100, Andreas Hindborg wrote:
> "Boqun Feng" <boqun@...nel.org> writes:
> 
> > On Sat, Jan 31, 2026 at 02:19:05PM +0100, Andreas Hindborg wrote:
> > [..]
> >> >
> >> > However, byte-wise atomic memcpy will be more defined without paying any
> >> > extra penalty.
> >>
> >> Could you explain the additional penalty of `core::ptr::read_volatile`
> >> vs `kernel::sync::atomic::Atomic::load` with  relaxed ordering?
> >>
> >
> > I don't understand your question, so allow me to explain what I meant:
> > for the sake of discussion, let's assume we have both
> >
> > 	fn volatile_copy_memory(src: *mut u8, dst: *mut u8, count: usize)
> >
> > and
> >
> > 	fn volatile_byte_wise_atomic_copy_memory(<same signature>, ordering: Ordering)
> >
> > implemented. What I meant was to the best of my knowledge, when ordering
> > = Relaxed, these two would generate the exact same code because all the
> > architectures that I'm aware of have byte wise atomicity in the
> > load/store instructions. And compared to volatile_copy_memory(),
> > volatile_byte_wise_atomic_copy_memory() can bear the race with another
> > volatile_byte_wise_atomic_copy_memory() or any other atomic access
> > (meaning that's not a UB). So I'd prefer using that if we have it.
> 
> Ok, thanks for clarifying. I assumed you were referring to the other
> functions I mentioned, because they exist in `kernel` or `core`.
> `volatile_copy_memory` is unstable in `core`, and as far as I know
> `volatile_byte_wise_atomic_copy_memory` does not exist.

I was using volatile_byte_wise_atomic_copy_memory() to represent the
concept that we have a volatile byte-wise atomic memcpy. I was trying to
discuss the performance difference (which is 0) between a "volatile
memory copy" and "a volatile byte-wise atomic memory copy" based on
these concepts to answer your question about the "penalty" part of my
previous reply.

> 
> When you wrote `read_volatile`, I assumed you meant
> `core::ptr::read_volatile`, and the atomics we have are
> `kernel::sync::atomic::*`.

It was the curse of knowledge, when I referred to "byte-wise atomic
memcpy", I meant the concept of this [1], i.e. a memcpy that provides
atomicity of each byte.

[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1478r7.html

> 
> So now I am a bit confused as to what method you think is usable here.
> Is it something we need to implement?
> 

First, since the length of the copy is not fixed, we will need something
like `volatile_copy_memcpy()` to handle that. So I need to take back my
previous suggestion about using `read_volatile()`, not because it would
cause UB, but because it doesn't handle variable lengths.

But if there could be a concurrent writer to the page we are copying
from, we need a `volatile_byte_wise_atomic_copy_memory()` that we need
either implement on our own or ask Rust to provide one.

Does this help?

Regards,
Boqun

> Best regards,
> Andreas Hindborg
> 
> 
> 

Powered by blists - more mailing lists