From: Peter Zijlstra <peterz@infradead.org>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Gary Guo" <gary@garyguo.net>, "Boqun Feng" <boqun@kernel.org>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"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>,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
linux-mm@kvack.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rust: page: add byte-wise atomic memory copy methods
Date: Wed, 18 Feb 2026 11:09:15 +0100 [thread overview]
Message-ID: <20260218100915.GB1395266@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <aZWGq8EMxz4omw4L@google.com>
On Wed, Feb 18, 2026 at 09:31:13AM +0000, Alice Ryhl wrote:
> > Must we really go write things like:
> >
> > struct foo val, *ptr;
> >
> > ptr = kmap_local_page(page);
> > memcpy(ptr, val, sizeof(val));
> > kunmap_local(ptr);
> >
> > ptr = RELOC_HIDE(&val, 0);
> >
> > if (ptr->field) {
> > ...
> > }
> >
> > That seems 'unfortunate'. It basically means we must never use local
> > stack for copies or somesuch.
>
> No I don't think RELOC_HIDE is what you want to be using here.
>
> The way to stop the compiler from doing this is to ensure that, in
> LLVM's eyes, the memcpy is either a volatile memcpy, an atomic memcpy,
> or an opaque function call. According to Gary's reply to my email on V3,
> it sounds like an explicit call to memcpy like this apparently falls into
> opaque function call, so it should be okay.
Ah, so we should write:
struct foo val, *ptr;
ptr = kmap_local_page(page);
__memcpy(ptr, val, sizeof(val));
kunmap_local(ptr);
if (val.field) {
...
}
That forces things to be a function call since it elides the C memcpy
intrinsic for not having the right name.
But that also elides KASAN and such that want to hijack the various mem
functions for instrumentation purposes.
next prev parent reply other threads:[~2026-02-18 10:18 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 14:51 Andreas Hindborg
2026-02-12 16:41 ` Boqun Feng
2026-02-12 17:10 ` Andreas Hindborg
2026-02-12 17:23 ` Andreas Hindborg
2026-02-13 9:55 ` Peter Zijlstra
2026-02-13 12:18 ` Greg KH
2026-02-13 12:58 ` Andreas Hindborg
2026-02-13 13:20 ` Greg KH
2026-02-13 14:13 ` Andreas Hindborg
2026-02-13 14:26 ` Peter Zijlstra
2026-02-13 15:34 ` Greg KH
2026-02-13 15:45 ` Boqun Feng
2026-02-13 15:58 ` Greg KH
2026-02-13 16:19 ` Boqun Feng
2026-02-17 9:13 ` Peter Zijlstra
2026-02-17 9:33 ` Alice Ryhl
2026-02-17 9:45 ` Peter Zijlstra
2026-02-17 10:01 ` Alice Ryhl
2026-02-17 10:25 ` Peter Zijlstra
2026-02-17 10:47 ` Alice Ryhl
2026-02-17 11:09 ` Peter Zijlstra
2026-02-17 11:51 ` Alice Ryhl
2026-02-17 12:09 ` Peter Zijlstra
2026-02-17 13:00 ` Peter Zijlstra
2026-02-17 13:54 ` Danilo Krummrich
2026-02-17 15:50 ` Peter Zijlstra
2026-02-17 16:10 ` Danilo Krummrich
2026-02-17 13:09 ` Alice Ryhl
2026-02-17 15:48 ` Peter Zijlstra
2026-02-17 23:39 ` Gary Guo
2026-02-18 8:37 ` Peter Zijlstra
2026-02-18 9:31 ` Alice Ryhl
2026-02-18 10:09 ` Peter Zijlstra [this message]
2026-02-17 13:56 ` Andreas Hindborg
2026-02-17 16:04 ` Peter Zijlstra
2026-02-17 18:43 ` Andreas Hindborg
2026-02-17 20:32 ` Jens Axboe
2026-02-17 15:52 ` Boqun Feng
2026-02-17 9:17 ` Peter Zijlstra
2026-02-17 9:23 ` Peter Zijlstra
2026-02-17 9:37 ` Alice Ryhl
2026-02-17 10:01 ` Peter Zijlstra
2026-02-17 9:33 ` Peter Zijlstra
2026-02-14 0:07 ` Gary Guo
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=20260218100915.GB1395266@noisy.programming.kicks-ass.net \
--to=peterz@infradead.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=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lossin@kernel.org \
--cc=mark.rutland@arm.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox