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: <CANiq72=3MR9F9ur-aQYP4P81RBreAr=UiGg5iaSuFjjd5Q4Y7Q@mail.gmail.com>
Date: Tue, 11 Feb 2025 22:37:26 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Yury Norov <yury.norov@...il.com>
Cc: 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>, 
	Jason Gunthorpe <jgg@...dia.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V8 04/14] rust: Add cpumask helpers

On Tue, Feb 11, 2025 at 5:24 PM Yury Norov <yury.norov@...il.com> wrote:
>
> No, not Okay.
>
> To begin with, this is the 8th version of the same patch, but you
> only now bothered to CC someone who is listed in MAINTAINERS. This is
> not how the community works.

Yeah, that is not good.

For what it is worth, we try to make this very clear:

    https://rust-for-linux.com/contributing#submitting-new-abstractions-and-modules

i.e. that maintainers need to be Cc'd and contacted as soon as
possible (possibly even before writing the code).

> You also made it a patch bomb that touches multiple critical and very
> sensitive subsystems. You link them to an experimental and unstable
> project, and do it in a way that makes it really easy to slip through
> maintainers' attention.

Not sure what you mean by "unstable project", but I agree that the
patch series, unless Viresh is the maintainer of the C side of
everything added, it should be discussed and maintenance discussed
accordingly before merging anything.

This is what we have done for everything else, and that has not changed.

I try to spot cases where this is not done, which is why I Cc'd you in
v7 and told Viresh to please do so, and he did -- I don't think he was
trying to bypass on purpose:

    https://lore.kernel.org/rust-for-linux/CANiq72=o+uc3ZnNrdkuoSGSL8apNE4z4QwpvsiLfGzXFywSLrQ@mail.gmail.com/

> That would make things even worse. Before you wanted me to maintain
> rust linkage. Now you want me to get approval from someone else who
> maintains rust linkage. In case I need to change something, I want to
> be able to just change.

Like Danilo mentions, there are several ways to go forward here. For
some ideas/context, please see:

    https://rust-for-linux.com/rust-kernel-policy#how-is-rust-introduced-in-a-subsystem

(Thanks Jason for linking the page)

And, yeah, whoever ends up maintaining this, then they should of
course be testing it properly with Rust enabled with a proper config
for that and so on, just like one would do for anything else. By the
way, it is possible to request Intel's 0day to build with Rust
enabled.

(Side-note: to clarify, there are different parties involved here --
"Rust team" is fairly ambiguous.)

Cheers,
Miguel