From: Boqun Feng <boqun@kernel.org>
To: Andreas Hindborg <a.hindborg@kernel.org>
Cc: "Gary Guo" <gary@garyguo.net>,
"Alice Ryhl" <aliceryhl@google.com>,
"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
linux-mm@kvack.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: page: add volatile memory copy methods
Date: Sat, 31 Jan 2026 11:30:33 -0800 [thread overview]
Message-ID: <aX5YWdBxPmPrTLDA@tardis.local> (raw)
In-Reply-To: <87jywxr42q.fsf@t14s.mail-host-address-is-not-set>
On Sat, Jan 31, 2026 at 08:10:21PM +0100, Andreas Hindborg wrote:
> "Boqun Feng" <boqun@kernel.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
>
>
>
next prev parent reply other threads:[~2026-01-31 19:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 12:33 [PATCH] rust: page: add volatile memory copy methods Andreas Hindborg
2026-01-30 13:10 ` Gary Guo
2026-01-30 13:48 ` Andreas Hindborg
2026-01-30 14:14 ` Gary Guo
2026-01-30 14:42 ` Andreas Hindborg
2026-01-30 15:04 ` Gary Guo
2026-01-30 15:23 ` Andreas Hindborg
2026-01-30 15:48 ` Gary Guo
2026-01-30 16:20 ` Andreas Hindborg
2026-01-30 21:41 ` Boqun Feng
2026-01-31 7:22 ` Boqun Feng
2026-01-31 13:34 ` Andreas Hindborg
2026-01-31 16:09 ` Gary Guo
2026-01-31 20:30 ` Andreas Hindborg
2026-01-31 20:48 ` Gary Guo
2026-01-31 21:31 ` Andreas Hindborg
2026-02-03 1:07 ` Boqun Feng
2026-02-04 13:16 ` Andreas Hindborg
2026-02-04 13:48 ` Alice Ryhl
2026-02-04 15:58 ` Andreas Hindborg
2026-02-04 16:12 ` Gary Guo
2026-02-12 14:21 ` Andreas Hindborg
2026-01-31 16:26 ` Boqun Feng
2026-01-31 20:14 ` Andreas Hindborg
2026-01-31 13:19 ` Andreas Hindborg
2026-01-31 16:43 ` Boqun Feng
2026-01-31 19:10 ` Andreas Hindborg
2026-01-31 19:30 ` Boqun Feng [this message]
2026-01-31 20:20 ` Andreas Hindborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aX5YWdBxPmPrTLDA@tardis.local \
--to=boqun@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.