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: <aX4xNxsF5Qs0CTPW@tardis.local>
Date: Sat, 31 Jan 2026 08:43:35 -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: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.

Regards,
Boqun

> 
> Best regards,
> Andreas Hindborg
> 
>