From: Ralf Jung <post@ralfj.de>
To: Andreas Hindborg <a.hindborg@kernel.org>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
"Boqun Feng" <boqun.feng@gmail.com>, comex <comexk@gmail.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Abdiel Janulgue" <abdiel.janulgue@gmail.com>,
dakr@kernel.org, robin.murphy@arm.com,
rust-for-linux@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Valentin Obst" <kernel@valentinobst.de>,
linux-kernel@vger.kernel.org, "Christoph Hellwig" <hch@lst.de>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
airlied@redhat.com, iommu@lists.linux.dev, lkmm@lists.linux.dev
Subject: Re: Allow data races on some read/write operations
Date: Tue, 18 Mar 2025 15:44:50 +0100 [thread overview]
Message-ID: <ab8fd525-9a63-46e2-a443-b9d94eed6004@ralfj.de> (raw)
In-Reply-To: <87frjp5iyn.fsf@kernel.org>
Hi all,
>>> I
>>> may even later copy the data at place B to place C where C might have
>>> concurrent reads and/or writes, and the kernel will not experience UB
>>> because of this. The data may be garbage, but that is fine. I am not
>>> interpreting the data, or making control flow decisions based on it. I
>>> am just moving the data.
>>>
>>> My understand is: In Rust, this program would be illegal and might
>>> experience UB in unpredictable ways, not limited to just the data that
>>> is being moved.
>>
>> That is correct. C and Rust behave the same here.
>
> Is there a difference between formal models of the languages and
> practical implementations of the languages here? I'm asking this because
> C kernel developers seem to be writing these programs that are illegal
> under the formal spec of the C language, but work well in practice.
> Could it be the same in Rust?
>
> That is, can I do this copy and get away with it in practice under the
> circumstances outlined earlier?
As with off-label drug usage, things can of course go well even if you
deliberately leave the range of well-defined usage defined by the manufacturer.
However, answering your question conclusively requires intimate knowledge of the
entire compilation chain. I'm not even sure if there's a single person that has
everything from front-end transformations to back-end lowering in their head...
At the scale that compilers have reached, I think we have to compartmentalize by
establishing abstractions (such as the Rust / C language specs, and the LLVM IR
language spec). This enables each part of the compiler to locally ensure their
consistency with the spec (hopefully that one part still fits in one person's
head), and as long as everyone uses the same spec and interprets it the same
way, we achieve a consistent end-to-end result from many individually consistent
pieces.
Personally my goal has always been to identify the cases where programmers
deliberately reach for such off-label usage, figure out the missing parts in the
language that motivate them to do this, and add them, so that we can move on
having everything on solid footing. :) I did not realize that atomic memcpy is
so crucial for the kernel, but it makes sense in hindsight. So IMO that is where
we should spend our effort, rather than digging through the entire compilation
pipeline to determine some works-in-practice off-label alternative.
>>> One option I have explored is just calling C memcpy directly, but
>>> because of LTO, that is no different than doing the operation in Rust.
>>>
>>> I don't think I need atomic memcpy, I just need my program not to
>>> explode if I move some data to or from a place that is experiencing
>>> concurrent writes without synchronization. Not in general, but for some
>>> special cases where I promise not to look at the data outside of moving
>>> it.
>>
>> I'm afraid I do not know of a language, other than assembly, that can provide this.
>>
>> Atomic memcpy, however, should be able to cover your use-case, so it seems like
>> a reasonable solution to me? Marking things as atomic is literally how you tell
>> the compiler "don't blow up if there are concurrent accesses".
>
> If atomic memcpy is what we really need to write these kinds of programs in
> Rust, what would be the next steps to get this in the language?
There is an RFC, but it has been stalled for a while:
<https://github.com/rust-lang/rfcs/pull/3301>. I do not know its exact status.
It might be blocked on having this in the C++ model, though at least unstable
experimentation should be possible before C++ has fully standardized the way
this will look. (We'll want to ensure consistency of the C++ and Rust models
here to ensure that C, C++, and Rust can interop on shared memory in a coherent
way.)
On the C++ side (where the atomic memcpy would likely be added to the
concurrency memory model, to be then adopted by C and Rust), I heard there was a
lot of non-technical trouble due to ISO changing their procedural rules for how
they wanted changes to the standard to look like. I don't know any further
details here as I am not directly involved.
> Also, would there be a performance price to pay for this?
I know little about evaluating performance at the low-level architectural or
even microarchitectural level. However I would think in the end the memcpy
itself (when using the "relaxed" atomic ordering) would be the same existing
operation, the same assembly, it is just treated differently by optimizations
before reaching the assembly stage.
Kind regards,
Ralf
>
>
> Best regards,
> Andreas Hindborg
>
>
>
next prev parent reply other threads:[~2025-03-18 14:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6dea7b6a-1534-47e7-94d2-d67417c3d4c1@proton.me>
[not found] ` <tnwDK3QN_Xr0Yoa3U8HVxS5OqjvxIhgmmO_ifTGJR_EtIzjoxawOHtnbOJ9yChsUWXyFPcU9beIdrgbpfGZI8w==@protonmail.internalid>
[not found] ` <3202F69F-397E-4BC4-8DD8-E2D4B0AB056F@collabora.com>
[not found] ` <87bjuil15w.fsf@kernel.org>
[not found] ` <t4HxdvR7WBX_861hiTXo72jqC9F9oRpIzgA_dD2yhcSuLISEkC-shMfSgllrFPpnkSZXGfRcc47keudMooNiIQ==@protonmail.internalid>
[not found] ` <CAH5fLgg5MuUu=TX8mMsPf5RcLhMLHSU4Vct=h8rFX6Z7HjPxeA@mail.gmail.com>
[not found] ` <87ikoqjg1n.fsf@kernel.org>
[not found] ` <KpWTCfIlcLYFBpSvWPfALJ9VQn5a99_RAvxgMBc1aCrSalPB-qaW9IhXyaDG7HM1AcFPX5chj_Yr7IQp3F7UqA==@protonmail.internalid>
[not found] ` <CAH5fLgh6ubawHh76wq7JPbcuBCWhm91m7Rc01MVsX-a3C6qaVA@mail.gmail.com>
[not found] ` <87mse2hrd8.fsf@kernel.org>
2025-03-03 20:08 ` Allow data races on some read/write operations Boqun Feng
2025-03-04 19:03 ` Ralf Jung
2025-03-04 20:18 ` comex
2025-03-05 3:24 ` Boqun Feng
2025-03-05 13:10 ` Ralf Jung
2025-03-05 13:23 ` Alice Ryhl
2025-03-05 13:27 ` Ralf Jung
2025-03-05 14:40 ` Robin Murphy
2025-03-05 18:43 ` Andreas Hindborg
2025-03-05 19:30 ` Alan Stern
2025-03-05 19:42 ` Ralf Jung
2025-03-05 21:26 ` Andreas Hindborg
2025-03-05 21:53 ` Ralf Jung
2025-03-07 8:43 ` Andreas Hindborg
2025-03-18 14:44 ` Ralf Jung [this message]
2025-03-05 18:41 ` Andreas Hindborg
2025-03-05 14:25 ` Daniel Almeida
2025-03-05 18:38 ` Andreas Hindborg
2025-03-05 22:01 ` Ralf Jung
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=ab8fd525-9a63-46e2-a443-b9d94eed6004@ralfj.de \
--to=post@ralfj.de \
--cc=a.hindborg@kernel.org \
--cc=abdiel.janulgue@gmail.com \
--cc=airlied@redhat.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=comexk@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=kernel@valentinobst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=m.szyprowski@samsung.com \
--cc=ojeda@kernel.org \
--cc=robin.murphy@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).