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: <87frkfv8eu.fsf@kernel.org>
Date: Sat, 15 Feb 2025 10:55:53 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: "Jason Gunthorpe" <jgg@...dia.com>,  "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>,  "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>,  "Greg KH" <gregkh@...uxfoundation.org>,
  "Philipp Stanner" <phasta@...lbox.org>,  "Jens Axboe" <axboe@...nel.dk>
Subject: Re: [PATCH V8 04/14] rust: Add cpumask helpers

"Miguel Ojeda" <miguel.ojeda.sandonis@...il.com> writes:

> On Fri, Feb 14, 2025 at 10:06 PM Jason Gunthorpe <jgg@...dia.com> wrote:

[...]

>> As a side note, I don't see how anyone can enact this plan without the
>> support of Linus to do CONFIG_RUST=n builds and put out a non-working
>> rc1. IMHO it is yet unclear if this is real thing or an unproven idea
>> block has that will run into problems.
>
> Please ask Jens and the block layer -- Cc'ing Jens (Andreas and Boqun
> are already Cc'd):
>
>     https://lore.kernel.org/all/593a98c9-baaa-496b-a9a7-c886463722e1@kernel.dk/
>
> Having said that, I am not sure what you mean by -rc1. It is in the
> context of a friendly collaboration -- I assume the intention is that
> Andreas et al. are given enough lead time on new features to fix them
> before the merge window. For fixes, it may be harder, of course. Other
> ideas: they may be able to config out certain parts too; or in the
> worst case, in an emergency, Linus may decide to break Rust. They may
> be able to tell you the details of their plan.

Maybe I can help move the discussion forward by describing how we do
things in block.

In block we (the block subsystem community) currently have the rule that
rust code should not delay shipping a PR. I am not sure how Jens will
enforce this, but I could imagine that if builds start failing by the
time a PR has to be submitted, Jens would just yank rust block code. And
so no fallout of this would reach Linus.

Of course, there may be situations where problems do not surface until
Linux is merging things, but for this to happen without these issues
first appearing in linux-next would be extremely unlikely.

Maybe having a config option to disable rust block might be a good idea,
to prevent the yanking if it ever comes to that.

In practice, we never had any issues. Things have broken a handful of
times, but I usually see it within 24 ours and then I am able to send a
fix.

I can't imagine that Jens has been forced to spend a lot of cycles on
this, outside of applying a few fixes now and again. It would be
interesting to know how much the workload has actually been for him.

Anyways, it is my hope that within a few years, rust will become a fully
qualified citizen in block, and the special rule can be dropped. This of
course requires Jens becoming able and willing to handle rust related
issues himself, or him becoming confident that the current arrangement
will suffice for solving any rust related issues.


Best regards,
Andreas Hindborg



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ