[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whvzK6ugXhCdrTfXnkFR+u_+sCtwz4aDODJ_h-RJ3kOKw@mail.gmail.com>
Date: Wed, 26 Feb 2025 15:18:48 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Martin Uecker <uecker@...raz.at>, Ralf Jung <post@...fj.de>,
"Paul E. McKenney" <paulmck@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Ventura Jack <venturajack85@...il.com>, Kent Overstreet <kent.overstreet@...ux.dev>,
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 Wed, 26 Feb 2025 at 14:34, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Correct, but if the variable had some other protection, like a lock held
> when this function was called, it is fine to do and the compiler may
> optimize it or not and still have the same result.
Sure.
But locking isn't always there. And shouldn't always be there. Lots of
lockless algorithms exist, and some of them are very simple indeed ("I
set a flag, you read a flag, you get one or the other value")
Linus
Powered by blists - more mailing lists