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: <20250211164938.GI3754072@nvidia.com>
Date: Tue, 11 Feb 2025 12:49:38 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	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
Subject: Re: [PATCH V8 04/14] rust: Add cpumask helpers

On Tue, Feb 11, 2025 at 11:24:55AM -0500, Yury Norov wrote:
> I'm particularly concerned with the following comment from Jason
> Gunthorpe:
> 
>   All PRs to Linus must not break the rust build and the responsibilty
>   for that falls to all the maintainers. If the Rust team is not quick
>   enough to resolve any issues during the development window then
>   patches must be dropped before sending PRs, or Linus will refuse the
>   PR.
> 
> https://lore.kernel.org/lkml/20250130154646.GA2298732@nvidia.com/
> 
> And that happened at least once, right?

Yes, 6 patches were dropped from the last merge window by Andrew and
Linus because of rust build breakage.

There has since been some clarification posted:

 https://lore.kernel.org/all/CANiq72m-R0tOakf=j7BZ78jDHdy=9-fvZbAT8j91Je2Bxy0sFg@mail.gmail.com/

Quoting:

   Who is responsible if a C change breaks a build with Rust enabled?

    The usual kernel policy applies. So, by default, changes should not
    be introduced if they are known to break the build, including Rust.

    However, exceptionally, for Rust, a subsystem may allow to
    temporarily break Rust code. The intention is to facilitate friendly
    adoption of Rust in a subsystem without introducing a burden to
    existing maintainers who may be working on urgent fixes for the C
    side. The breakage should nevertheless be fixed as soon as possible,
    ideally before the breakage reaches Linus.

    For instance, this approach was chosen by the block laye
    they called it "stage 1" in their Rust integration plan.

    We believe this approach is reasonable as long as the kernel does not
    have way too many subsystems doing that (because otherwise it would be
    very hard to build e.g. linux-next).

However, it is unclear how this "temporarily break Rust code" will
work in practice. We do not know under what conditions Linus will
accept a PR that forces him to go to CONFIG_RUST=n, or even if Linus
has agreed to this exception policy.

I suggest the safe thing for any maintainer is to not send Linus PRs
that break rust, otherwise they get to be a test case to see what
happens..

Jason