From: Martin Uecker <uecker@tugraz.at>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ralf Jung <post@ralfj.de>,
"Paul E. McKenney" <paulmck@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Ventura Jack <venturajack85@gmail.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
Gary Guo <gary@garyguo.net>,
airlied@gmail.com, boqun.feng@gmail.com,
david.laight.linux@gmail.com, ej@inai.de,
gregkh@linuxfoundation.org, hch@infradead.org, hpa@zytor.com,
ksummit@lists.linux.dev, linux-kernel@vger.kernel.org,
miguel.ojeda.sandonis@gmail.com, rust-for-linux@vger.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)
Date: Thu, 27 Feb 2025 05:18:22 +0100 [thread overview]
Message-ID: <09e282a9c02fb07ba4fc248f14c0173d9b19179a.camel@tugraz.at> (raw)
In-Reply-To: <CAHk-=whLSWX=-5-z4Q8x1f_NLrHd0e3afbEwYPkkVSXj=xT-JQ@mail.gmail.com>
Am Mittwoch, dem 26.02.2025 um 13:14 -0800 schrieb Linus Torvalds:
> On Wed, 26 Feb 2025 at 12:00, Martin Uecker <uecker@tugraz.at> wrote:
[...]
>
> That "single read done as multiple reads" is sadly still accepted by
> the C standard, as far as I can tell. Because the standard still
> considers it "unobservable" unless I've missed some update.
>
> Please do better than that.
This is not really related to "observable" but to visibility
of stores to other threads.
It sounds you want to see the semantics strengthened in case
of a data race from there being UB to having either the old
or new value being visible to another thread, where at some
point this could change but needs to be consistent for a
single access as expressed in the source code.
This does sound entirely resonable to me and if compilers
already do behave this way (though Paul's comment
seems to imply otherwise), then I think the standard
could easily be changed to ensure this. I do some work to
remove UB and I was already thinking about what could
be done here.
But somebody would have to do the work and propose this. *)
Such a change would need to come with a precise enough
explanation what needs to change and a clear rationale.
My guess is that if one could convince compiler people
- especially those from the clang side that are the most
critical in my experience - then such a proposal would
actually have a very good chance to be accepted.
There would certainly be opposition if this fundamentally
diverges from C++ because no compiler framework will seriously
consider implementing a completely different memory model
for C (or for Rust) than for C++.
I could also imagine that the problem here is that it is
actually very difficult for compilers to give the guarantess
you want, because they evolved from compilers
doing optimization for single threads and and one would
have to fix a lot of issues in the optimizers. So the
actually problem here might be that nobody wants to pay
for fixing the compilers.
Martin
*): https://www.open-std.org/jtc1/sc22/wg14/www/contributing.html
next prev parent reply other threads:[~2025-02-27 4:18 UTC|newest]
Thread overview: 196+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-22 10:06 Ventura Jack
2025-02-22 14:15 ` Gary Guo
2025-02-22 15:03 ` Ventura Jack
2025-02-22 18:54 ` Kent Overstreet
2025-02-22 19:18 ` Linus Torvalds
2025-02-22 20:00 ` Kent Overstreet
2025-02-22 20:54 ` H. Peter Anvin
2025-02-22 21:22 ` Kent Overstreet
2025-02-22 21:46 ` Linus Torvalds
2025-02-22 22:34 ` Kent Overstreet
2025-02-22 23:56 ` Jan Engelhardt
2025-02-22 22:12 ` David Laight
2025-02-22 22:46 ` Kent Overstreet
2025-02-22 23:50 ` H. Peter Anvin
2025-02-23 0:06 ` Kent Overstreet
2025-02-22 21:22 ` Linus Torvalds
2025-02-23 15:30 ` Ventura Jack
2025-02-23 16:28 ` David Laight
2025-02-24 0:27 ` Gary Guo
2025-02-24 9:57 ` Ventura Jack
2025-02-24 10:31 ` Benno Lossin
2025-02-24 12:21 ` Ventura Jack
2025-02-24 12:47 ` Benno Lossin
2025-02-24 16:57 ` Ventura Jack
2025-02-24 22:03 ` Benno Lossin
2025-02-24 23:04 ` Ventura Jack
2025-02-25 22:38 ` Benno Lossin
2025-02-25 22:47 ` Miguel Ojeda
2025-02-25 23:03 ` Benno Lossin
2025-02-24 12:58 ` Theodore Ts'o
2025-02-24 14:47 ` Miguel Ojeda
2025-02-24 14:54 ` Miguel Ojeda
2025-02-24 16:42 ` Philip Herron
2025-02-25 15:55 ` Ventura Jack
2025-02-25 17:30 ` Arthur Cohen
2025-02-26 11:38 ` Ralf Jung
2025-02-24 15:43 ` Miguel Ojeda
2025-02-24 17:24 ` Kent Overstreet
2025-02-25 16:12 ` Alice Ryhl
2025-02-25 17:21 ` Ventura Jack
2025-02-25 17:36 ` Alice Ryhl
2025-02-25 18:16 ` H. Peter Anvin
2025-02-25 20:21 ` Kent Overstreet
2025-02-25 20:37 ` H. Peter Anvin
2025-02-26 13:03 ` Ventura Jack
2025-02-26 13:53 ` Miguel Ojeda
2025-02-26 14:07 ` Ralf Jung
2025-02-26 14:26 ` James Bottomley
2025-02-26 14:37 ` Ralf Jung
2025-02-26 14:39 ` Greg KH
2025-02-26 14:45 ` James Bottomley
2025-02-26 16:00 ` Steven Rostedt
2025-02-26 16:42 ` James Bottomley
2025-02-26 16:47 ` Kent Overstreet
2025-02-26 16:57 ` Steven Rostedt
2025-02-26 17:41 ` Kent Overstreet
2025-02-26 17:47 ` Steven Rostedt
2025-02-26 22:07 ` Josh Poimboeuf
2025-03-02 12:19 ` David Laight
2025-02-26 17:11 ` Miguel Ojeda
2025-02-26 17:42 ` Kent Overstreet
2025-02-26 12:36 ` Ventura Jack
2025-02-26 13:52 ` Miguel Ojeda
2025-02-26 15:21 ` Ventura Jack
2025-02-26 16:06 ` Ralf Jung
2025-02-26 17:49 ` Miguel Ojeda
2025-02-26 18:36 ` Ventura Jack
2025-02-26 14:14 ` Ralf Jung
2025-02-26 15:40 ` Ventura Jack
2025-02-26 16:10 ` Ralf Jung
2025-02-26 16:50 ` Ventura Jack
2025-02-26 21:39 ` Ralf Jung
2025-02-27 15:11 ` Ventura Jack
2025-02-27 15:32 ` Ralf Jung
2025-02-25 18:54 ` Linus Torvalds
2025-02-25 19:47 ` Kent Overstreet
2025-02-25 20:25 ` Linus Torvalds
2025-02-25 20:55 ` Kent Overstreet
2025-02-25 21:24 ` Linus Torvalds
2025-02-25 23:34 ` Kent Overstreet
2025-02-26 11:57 ` Gary Guo
2025-02-27 14:43 ` Ventura Jack
2025-02-26 14:26 ` Ventura Jack
2025-02-25 22:45 ` Miguel Ojeda
2025-02-26 0:05 ` Miguel Ojeda
2025-02-25 22:42 ` Miguel Ojeda
2025-02-26 14:01 ` Ralf Jung
2025-02-26 13:54 ` Ralf Jung
2025-02-26 17:59 ` Linus Torvalds
2025-02-26 19:01 ` Paul E. McKenney
2025-02-26 20:00 ` Martin Uecker
2025-02-26 21:14 ` Linus Torvalds
2025-02-26 21:21 ` Linus Torvalds
2025-02-26 22:54 ` David Laight
2025-02-27 0:35 ` Paul E. McKenney
2025-02-26 21:26 ` Steven Rostedt
2025-02-26 21:37 ` Steven Rostedt
2025-02-26 21:42 ` Linus Torvalds
2025-02-26 21:56 ` Steven Rostedt
2025-02-26 22:13 ` Steven Rostedt
2025-02-26 22:22 ` Linus Torvalds
2025-02-26 22:35 ` Steven Rostedt
2025-02-26 23:18 ` Linus Torvalds
2025-02-26 23:28 ` Steven Rostedt
2025-02-27 0:04 ` Linus Torvalds
2025-02-27 20:47 ` David Laight
2025-02-27 21:33 ` Steven Rostedt
2025-02-28 21:29 ` Paul E. McKenney
2025-02-27 21:41 ` Paul E. McKenney
2025-02-27 22:20 ` David Laight
2025-02-27 22:40 ` Paul E. McKenney
2025-02-28 7:44 ` Ralf Jung
2025-02-28 15:41 ` Kent Overstreet
2025-02-28 15:46 ` Boqun Feng
2025-02-28 16:04 ` Kent Overstreet
2025-02-28 16:13 ` Boqun Feng
2025-02-28 16:21 ` Kent Overstreet
2025-02-28 16:40 ` Boqun Feng
2025-03-04 18:12 ` Ralf Jung
2025-02-26 22:27 ` Kent Overstreet
2025-02-26 23:16 ` Linus Torvalds
2025-02-27 0:17 ` Kent Overstreet
2025-02-27 0:26 ` comex
2025-02-27 18:33 ` Ralf Jung
2025-02-27 19:15 ` Linus Torvalds
2025-02-27 19:55 ` Kent Overstreet
2025-02-27 20:28 ` Linus Torvalds
2025-02-28 7:53 ` Ralf Jung
2025-03-06 19:16 ` Ventura Jack
2025-02-27 4:18 ` Martin Uecker [this message]
2025-02-27 5:52 ` Linus Torvalds
2025-02-27 6:56 ` Martin Uecker
2025-02-27 14:29 ` Steven Rostedt
2025-02-27 17:35 ` Paul E. McKenney
2025-02-27 18:13 ` Kent Overstreet
2025-02-27 19:10 ` Paul E. McKenney
2025-02-27 18:00 ` Ventura Jack
2025-02-27 18:44 ` Ralf Jung
2025-02-27 14:21 ` Ventura Jack
2025-02-27 15:27 ` H. Peter Anvin
2025-02-28 8:08 ` Ralf Jung
2025-02-28 8:32 ` Martin Uecker
2025-02-26 20:25 ` Kent Overstreet
2025-02-26 20:34 ` Andy Lutomirski
2025-02-26 22:45 ` David Laight
2025-02-22 19:41 ` Miguel Ojeda
2025-02-22 20:49 ` Kent Overstreet
2025-02-26 11:34 ` Ralf Jung
2025-02-26 14:57 ` Ventura Jack
2025-02-26 16:32 ` Ralf Jung
2025-02-26 18:09 ` Ventura Jack
2025-02-26 22:28 ` Ralf Jung
2025-02-26 23:08 ` David Laight
2025-02-27 13:55 ` Ralf Jung
2025-02-27 17:33 ` Ventura Jack
2025-02-27 17:58 ` Ralf Jung
2025-02-27 19:06 ` Ventura Jack
2025-02-27 19:45 ` Ralf Jung
2025-02-27 20:22 ` Kent Overstreet
2025-02-27 22:18 ` David Laight
2025-02-27 23:18 ` Kent Overstreet
2025-02-28 7:38 ` Ralf Jung
2025-02-28 20:48 ` Ventura Jack
2025-02-28 20:41 ` Ventura Jack
2025-02-28 22:13 ` Geoffrey Thomas
2025-03-01 14:19 ` Ventura Jack
2025-03-04 18:24 ` Ralf Jung
2025-03-06 18:49 ` Ventura Jack
2025-02-27 17:58 ` Miguel Ojeda
2025-02-27 19:25 ` Ventura Jack
2025-02-26 19:07 ` Martin Uecker
2025-02-26 19:23 ` Ralf Jung
2025-02-26 20:22 ` Martin Uecker
[not found] <CAFJgqgRZ1w0ONj2wbcczx2=boXYHoLOd=-ke7tHGBAcifSfPUw@mail.gmail.com>
2025-02-25 15:42 ` H. Peter Anvin
2025-02-25 16:45 ` Ventura Jack
[not found] <CANiq72m-R0tOakf=j7BZ78jDHdy=9-fvZbAT8j91Je2Bxy0sFg@mail.gmail.com>
2025-02-18 16:08 ` Rust kernel policy Christoph Hellwig
2025-02-18 18:46 ` Miguel Ojeda
2025-02-18 21:49 ` H. Peter Anvin
2025-02-18 22:54 ` Miguel Ojeda
2025-02-19 0:58 ` H. Peter Anvin
2025-02-19 3:04 ` Boqun Feng
2025-02-19 5:39 ` Greg KH
2025-02-20 12:28 ` Jan Engelhardt
2025-02-20 12:37 ` Greg KH
2025-02-20 13:23 ` H. Peter Anvin
2025-02-20 15:17 ` C aggregate passing (Rust kernel policy) Jan Engelhardt
2025-02-20 16:46 ` Linus Torvalds
2025-02-20 20:34 ` H. Peter Anvin
2025-02-21 8:31 ` HUANG Zhaobin
2025-02-21 18:34 ` David Laight
2025-02-21 19:12 ` Linus Torvalds
2025-02-21 20:07 ` comex
2025-02-21 21:45 ` David Laight
2025-02-22 6:32 ` Willy Tarreau
2025-02-22 6:37 ` Willy Tarreau
2025-02-22 8:41 ` David Laight
2025-02-22 9:11 ` Willy Tarreau
2025-02-21 20:06 ` Jan Engelhardt
2025-02-21 20:23 ` Laurent Pinchart
2025-02-21 20:24 ` Laurent Pinchart
2025-02-21 22:02 ` David Laight
2025-02-21 22:13 ` Bart Van Assche
2025-02-22 5:56 ` comex
2025-02-21 20:26 ` Linus Torvalds
2025-02-21 22:19 ` henrychurchill
2025-02-21 22:52 ` henrychurchill
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=09e282a9c02fb07ba4fc248f14c0173d9b19179a.camel@tugraz.at \
--to=uecker@tugraz.at \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=boqun.feng@gmail.com \
--cc=david.laight.linux@gmail.com \
--cc=ej@inai.de \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=kent.overstreet@linux.dev \
--cc=ksummit@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=paulmck@kernel.org \
--cc=post@ralfj.de \
--cc=rust-for-linux@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=venturajack85@gmail.com \
/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