Re: linux-next: build failure after merge of the block tree

[Mark Brown]

On Wed, May 27, 2026 at 09:00:02AM -0600, Jens Axboe wrote:
> On 5/27/26 8:55 AM, Mark Brown wrote:
> > On Wed, May 27, 2026 at 08:39:16AM -0600, Jens Axboe wrote:

> >> Hmm, not sure we should let rust build issues gate whether a tree is
> >> current in -next or not. For, by far, most systems, it's not a
> >> requirement for a functional device.

> > That's also true for a huge proportion of the issues that get caught
> > with an allmodconfig, and allnoconfig is not exactly a realistic
> > configuration either.

> While that is true, the big difference here is that everybody should
> build allmodconfig themselves, but only a (much) smaller subset of those
> have rust enabled/available.

Personally I had to install a cross toolchain to be able to cover this
x86_64 stuff everyone seems to think is important. :)

More seriously I'd hope that people maintaining stuff that interacts
with rust have a rust toolchain available, it sounds like you do but it
silently got turned off without you realising.  If we're getting into a
situation where rust is routinely getting broken by not obviously
related stuff we might want to reevaluate that in general, not just for
-next but so far I've mostly seen what rust breakage I encounter be due
to rust specific changes which really ought to have been tested by
someone with a rust toolchain.  TBH given that rust conflicts come up
moderately often I think I need to have the build coverage just to catch
my own obvious errors.

> > that come up in people's coverage tests.  TBH the rust stuff originally
> > got turned on because I ran the allmodconfig on a machine that happened
> > to have a usable rustc installed, I was intending to enable it at some
> > point anyway.

> I think it's good to have coverage, but I think it should be more of the
> notification variety than a gating factor. For this particular time and
> branch it didn't matter, but sometimes I shove things in there that I
> absolutely need a quick test turn-around on. For exposure reasons. And
> getting a -next cycle delay on that would be unfortunate, and I think
> also unwarranted if the only issue is that the rust build broke.

OTOH part of what we're looking for is ensuring that we don't spend the
early part of the release cycle sorting out build issues that came in
during the merge window.  I agree that there's competing needs in there,
and we also have fun with things like both x86_64 and allmodconfig
turning on -Werror which opens us up to toolchain differences causing
trouble.

One trouble with notification only for things that break the build is
that it becomes hard to detect and work with it sensibly, and one build
break can easily mask another build break.

> Does highlight that apparently my build no longer does rust builds,
> which it did used to... Something to look into on my end.

Do you have KASAN turned on, or are you doing something like
allmodconfig which turns it on?  There was a change to make rust
incompatible with KASAN when used with GCC:

  https://lore.kernel.org/r/20260408-kasan-rust-sw-tags-v3-1-e07964d14363@xxxxxxxxxx

that caused me issues.

> Not trying to start a debate, just voicing my opinion on the matter :-)

Attachment: signature.asc
Description: PGP signature