linux-kernel - Re: [PATCH V8 04/14] rust: Add cpumask helpers

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: <20250214191103.GH3886819@nvidia.com>
Date: Fri, 14 Feb 2025 15:11:03 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Yury Norov <yury.norov@...il.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...hat.com>, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	linux-pm@...r.kernel.org,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Stephen Boyd <sboyd@...nel.org>, Nishanth Menon <nm@...com>,
	rust-for-linux@...r.kernel.org,
	Manos Pitsidianakis <manos.pitsidianakis@...aro.org>,
	Erik Schilling <erik.schilling@...aro.org>,
	Alex Bennée <alex.bennee@...aro.org>,
	Joakim Bech <joakim.bech@...aro.org>, Rob Herring <robh@...nel.org>,
	Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
	Uros Bizjak <ubizjak@...il.com>
Subject: Re: [PATCH V8 04/14] rust: Add cpumask helpers

On Fri, Feb 14, 2025 at 06:56:43PM +0100, Miguel Ojeda wrote:

> > I mean that Andrew's branch got broken because of it.

> We also never promised we would fix every single Rust issue spotted
> across the entire kernel. We try to do our best to help, though.

Sure, but it was said, by many people, many times, that "Rust is
allowed to break".

This is not just my incorrect impression. For instance read Philipp's
note to Christoph:

https://lore.kernel.org/all/293df3d54bad446e8fd527f204c6dc301354e340.camel@mailbox.org/

 > reassure you that the burden of keeping Rust abstractions working with
 > any changes on the C side rests entirely on the Rust side's shoulders?
 > (because that's what the statements made by the latter seem to mean to
 > me)

And Greg's version:

https://lore.kernel.org/all/2025013030-gummy-cosmic-7927@gregkh/

 > So the claim remains the same here.  It's just like staging, api changes
 > to subsystems are allowed to break staging, and rust code, and
 > maintainers do NOT have to fix them up there, that's up to the staging
 > and rust maintainers/developers to do so.

I've heard the same statements at conferences and in other coverages
like LWN. Frankly, I never much believed in this story as workable,
but it was advanced by many people to smooth the adoption of Rust
bindings.

>    https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers

I do not agree with "Didn't you promise Rust wouldn't be extra work
for maintainers?" in your document. Clearly there is a widespread
belief this kind of promise was made, even if it was never made by
you. "Rust is allowed to break" is understood to be the same as saying
it won't cause extra work.

However, I am glad we are seeing a more realistic understanding of
what Rust requires of the community over the long term.

Jason