linux-kernel - Re: Rust kernel policy

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: <20250226160554.GA33931@nvidia.com>
Date: Wed, 26 Feb 2025 12:05:54 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Danilo Krummrich <dakr@...nel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	rust-for-linux <rust-for-linux@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
	ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Sun, Feb 23, 2025 at 10:31:49AM -0800, Linus Torvalds wrote:
> On Sun, 23 Feb 2025 at 10:03, Laurent Pinchart
> <laurent.pinchart@...asonboard.com> wrote:
> >
> >   > I can't answer for Linus, sorry.  But a generic "hey, this broke our
> >   > working toolchain builds" is something that is much much much
> >   > different than "an api changed so I now have to turn off this driver
> >   > in my build" issue.
> >
> >   I haven't found a clear statement from Linus on this topic.
> >
> > Those three statements can't all be true together, we can at best have
> > two. I would like to understand which one we will drop first, and I
> > believe many other developers and maintainers are wondering the same.

> Yes, linux-next is supposed to catch interactions between different
> development trees. And yes, various build bots test different
> configurations. But nothing is ever perfect, and you really shouldn't
> expect it to be.

There are two "break" issues:
 1) Does rc1 work on a given system? We discussed this at the
    maintainer summit, and I think the consensus was it is sad it is
    broken so much but no changes were proposed. i386 being broken
    is this type of problem.

 2) Does Linus accept a PR from the maintainer? This is what I think
    Laurent is driving at. AFAIK Linus accepting a PR at least
    requires it passes your build test and boots your test machine(s).

IMHO, when a PR is rejected it is a big emergency for maintainers.
They carry the responsibility for all their submitters to get things
merged each cycle. Just dropping a whole PR is not an option.

So, this last cycle, Andrew rebased & dropped 6 patches from Uros and
resent his PR so all the other work got merged. Uros respun them based
on the discussion with you but Andrew didn't pick them up till after
the merge window (now commit eaac384d7eb3/etc in -next).

This is almost fine, except IMHO Andrew, should be build testing Rust
as well to catch this before you did to avoid this emergency last
minute rebase/revert.

I think Laurent's message is still evidence that the messaging to
maintainers needs to be crystal clear:

 It is the top level maintainer's responsibility to send Linus PRs
 that pass a CONFIG_RUST=y x86-64 allmodconfig (?) build.

To Laurent's point, my test here:

 https://lore.kernel.org/all/20250131135421.GO5556@nvidia.com/

Demonstrates maintainers cannot fully ignore the Rust bindings when
merging changes to the bound C API. The build CONFIG_RUST=y
immediately fails, and my understanding is that is enough for you to
probably refuse the PR.

Thus, at a minimum, the maintainer must track this and ensure things
are resolved *somehow* before sending the PR. [1]

The fact you have been seeing so few Rust breaks says that the
affected maintainers are already doing this. For instance Andreas
explains how he has been working to keep block's PR to you building:

 https://lore.kernel.org/all/87frkfv8eu.fsf@kernel.org/

Some examples of his work:
 31d813a3b8cb ("rust: block: fix use of BLK_MQ_F_SHOULD_MERGE")
 5b026e341207 ("rust: block: fix generated bindings after refactoring of features")
 5ddb88f22eb9 ("rust: block: do not use removed queue flag API")

IMHO, maintainers are smart people, tell them clearly this is what
they need to do and they will figure it out. None of this is
especially new or particularly different from what people are already
doing.

I keep going back to this topic because there really is alot of
confusing messaging out there. For instance I wrote this same
essential guideline earlier and I belive I was told it is not the
policy. I'm glad to see Miguel's latest policy document is clearer,
but I think it could be even more specific.

Regards,
Jason

1 - Laurent, I think the seeming conflict between "things are allowed
to break" and "Linus must get PRs that build CONFIG_RUST=y" should be
understood as meaning bisection safety is not required for Rust. Ie
per the block methodology there are commits in the PRs that fail
CONFIG_RUST=y builds. However, Jens must ensure it is fixed all up
somehow before sending the PR.