From: Andreas Hindborg <a.hindborg@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"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>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Onur Özkan" <work@onurozkan.dev>,
"Lyude Paul" <lyude@redhat.com>,
linux-mm@kvack.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, driver-core@lists.linux.dev
Subject: Re: [PATCH v5 0/4] rust: byte-wise atomic copies between `Page` and shared memory
Date: Wed, 11 Nov 2026 14:26:01 +0100 [thread overview]
Message-ID: <878q2zwlcm.fsf@t14s.mail-host-address-is-not-set> (raw)
In-Reply-To: <20261111093017.GX2668804@noisy.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> writes:
> On Tue, Nov 10, 2026 at 03:44:18PM +0100, Andreas Hindborg wrote:
>> This series adds a way to copy data between a `Page` and memory that is
>> shared with actors outside the kernel, such as user space threads or
>> hardware, without introducing a data race.
>>
>> The copy is built on `SysMem` from `kernel::io`, which already accesses
>> system memory with volatile or byte-wise atomic operations. The series
>> first makes the requirements of `SysMem` explicit by requiring freedom
>> from plain accesses for the lifetime of a view. It then adds
>> `atomic_per_byte_memcpy()`, a wrapper around the kernel's `memcpy()`
>> with explicit safety requirements, and routes the `SysMem` copies
>> through it. Finally, it adds `Page::{read,write}_bytewise_atomic`, which
>> take a `SysMem<'_, [u8]>` view of the shared buffer.
>
> I am still completely confused by this. In what universe is your magical
> atomic_per_byte_memcpy() not memcpy() ?
This Rust function is the C function `memcpy` in all known universes.
The commit message even says so.
There are safety requirements for calling the C `memcpy` from Rust. This
function makes them explicit.
If it helps, we can rename the function so that it is more clear that
this is in fact just `memcpy`. The current name was chosen to encode
some of the semantics of the function in the name.
`atomic_per_byte_memcpy` is different from the "regular" Rust memcpy
function `core::ptr::copy()`. `copre::ptr::copy()` is lowered by llvm
under the assumption of no concurrent accesses to the buffers on either
side of the operation, and so may generate code that is UB in Rust under
concurrent reads or writes. Examples of problems were given in v2.
We need a (Rust) function that can copy data from A to B in the face of
concurrent accesses without producing UB. This patch introduces such a
function, which happens to be just a call to the C `memcpy` function.
Letting every user call `bindings::memcpy` directly would also work, but
then every call site has to discover when that is OK. A Rust function
gives us one place to enumerate the safety requirements
Best regards,
Andreas Hindborg
prev parent reply other threads:[~2026-11-11 13:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 14:44 Andreas Hindborg
2026-11-10 14:44 ` [PATCH v5 1/4] rust: io: require freedom from plain accesses for `SysMem` Andreas Hindborg
2026-11-10 14:44 ` [PATCH v5 2/4] rust: sync: atomic: add atomic_per_byte_memcpy Andreas Hindborg
2026-11-10 14:44 ` [PATCH v5 3/4] rust: io: copy `SysMem` with `atomic_per_byte_memcpy` Andreas Hindborg
2026-11-10 14:44 ` [PATCH v5 4/4] rust: page: add byte-wise atomic copy methods for `SysMem` Andreas Hindborg
2026-11-11 9:30 ` [PATCH v5 0/4] rust: byte-wise atomic copies between `Page` and shared memory Peter Zijlstra
2026-11-11 13:26 ` Andreas Hindborg [this message]
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=878q2zwlcm.fsf@t14s.mail-host-address-is-not-set \
--to=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=mark.rutland@arm.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=will@kernel.org \
--cc=work@onurozkan.dev \
/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
all inboxes | Powered by JetHome®