lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025071651-daylong-brunette-ed9e@gregkh>
Date: Wed, 16 Jul 2025 14:54:34 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org, lkmm@...ts.linux.dev,
	linux-arch@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>, Will Deacon <will@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Lyude Paul <lyude@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	Mitchell Levy <levymitchell0@...il.com>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [PATCH v7 1/9] rust: Introduce atomic API helpers

On Wed, Jul 16, 2025 at 02:47:13PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 16, 2025 at 11:23:09AM +0200, Greg Kroah-Hartman wrote:
> > On Sun, Jul 13, 2025 at 10:36:48PM -0700, Boqun Feng wrote:
> > > In order to support LKMM atomics in Rust, add rust_helper_* for atomic
> > > APIs. These helpers ensure the implementation of LKMM atomics in Rust is
> > > the same as in C. This could save the maintenance burden of having two
> > > similar atomic implementations in asm.
> > > 
> > > Originally-by: Mark Rutland <mark.rutland@....com>
> > > Reviewed-by: Alice Ryhl <aliceryhl@...gle.com>
> > > Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> > > ---
> > >  rust/helpers/atomic.c                     | 1040 +++++++++++++++++++++
> > >  rust/helpers/helpers.c                    |    1 +
> > >  scripts/atomic/gen-atomics.sh             |    1 +
> > >  scripts/atomic/gen-rust-atomic-helpers.sh |   67 ++
> > >  4 files changed, 1109 insertions(+)
> > >  create mode 100644 rust/helpers/atomic.c
> > >  create mode 100755 scripts/atomic/gen-rust-atomic-helpers.sh
> > > 
> > > diff --git a/rust/helpers/atomic.c b/rust/helpers/atomic.c
> > > new file mode 100644
> > > index 000000000000..cf06b7ef9a1c
> > > --- /dev/null
> > > +++ b/rust/helpers/atomic.c
> > > @@ -0,0 +1,1040 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +
> > > +// Generated by scripts/atomic/gen-rust-atomic-helpers.sh
> > > +// DO NOT MODIFY THIS FILE DIRECTLY
> > 
> > As this is auto-generated, how do we know when to auto-generate it
> > again?  What files does it depend on?  And why can't we just
> > auto-generate it at build time instead of having a static file in the
> > tree that no one knows when to regenerate it?  :)
> 
> It depends on the scripts/atomic/* bits. They hardly if ever change. We
> do it this way because:
> 
>  - generating these files every build is 'slow'-ish;
>  - code navigation suffers;
>  - Linus asked for this.
> 
> Specifically, pretty much the entire atomic_*() namespace would
> disappear from ctags / code-browsing-tool-of-choice if we would not
> check in these files.

Ah, ok, that makes sense in a sad way.  As long as someone knows to
regenerate these files when needed, hopefully when the C files change
someone knows to update these rust ones...

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ