[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgYCS6=TFfRHz_aG1HNFBDyLMnHgkvi_=B03-tX-OBtOg@mail.gmail.com>
Date: Thu, 27 Feb 2025 12:28:12 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Ralf Jung <post@...fj.de>, Martin Uecker <uecker@...raz.at>,
"Paul E. McKenney" <paulmck@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Ventura Jack <venturajack85@...il.com>, Gary Guo <gary@...yguo.net>, airlied@...il.com,
boqun.feng@...il.com, david.laight.linux@...il.com, ej@...i.de,
gregkh@...uxfoundation.org, hch@...radead.org, hpa@...or.com,
ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
miguel.ojeda.sandonis@...il.com, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)
On Thu, 27 Feb 2025 at 11:55, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
>
> It's more explicit, and that's probably not a bad thing - compare it to
> our smp_mb__after_atomic(), it's not uncommon to find code where the
> barriers are missing because the person who wrote the code was assuming
> x86.
Sadly, judging by the memory ordering discussions I saw, I will almost
guarantee you that the compiler support for memory ordering will be
buggy.
When we miss details in our wrappers or our users, we can fix them.
And when the compilers mess up, we'll use the wrappers anyway.
Linus
Powered by blists - more mailing lists