linux-kernel - Re: [PATCH] rust: page: add volatile memory copy methods

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87jywxr42q.fsf@t14s.mail-host-address-is-not-set>
Date: Sat, 31 Jan 2026 20:10:21 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: Boqun Feng <boqun@...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

"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.

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

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

Best regards,
Andreas Hindborg