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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b17da8b5-6640-46ea-ba73-d2f4a08e246c@sirena.org.uk>
Date: Wed, 21 Jan 2026 14:56:52 +0000
From: Mark Brown <broonie@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Tamir Duberstein <tamird@...il.com>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Jens Axboe <axboe@...nel.dk>, Miguel Ojeda <ojeda@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the block tree

On Tue, Jan 20, 2026 at 11:08:40PM +0100, Miguel Ojeda wrote:

> Are you checking the `git status` after `make ... rustfmt` or similar?
> Otherwise, you may want to use `rustfmtcheck` instead.

I'll update my notes to rustfmtcheck, I presume that exits with an error
if it fails?  I'm not actually doing any of this Rust stuff yet, the
builds that are done are just what happens when all*config sees a Rust
toolchain installed.  I've got a small pile of things I'm going through
one at a time.  

We do really want things to respect O=, all the -next builds are using
that, so if anything shows up in the source tree that's a concern.  I am
bodging that for the kselftest build at the minute but it's not great.

> `CLIPPY=1` will catch stuff that we want to keep clean, i.e. if there
> is a positive, then it should be fixed, thus it would be great if it
> is run on linux-next integration. It will break the build with
> `WERROR=y` (it just adds more warnings to the compiler), so I think
> you should be able to just reuse your workflow/automation.

That is not going to be usable if it fails -Werror builds, Rust is only
enabled by the all*config configurations and they turn on -Werror
through the same process that they turn on Rust.  We really need -Werror
to pass.  I can set CLIPPY=1 for other configs then if they enable Rust
they'll need to pass cleanly but then it'll just explode when turned on
if there's lots of warnings which doesn't seem like it'll help Rust
adoption.  If we were starting from a point where the build was clean
then it'd be more viable.

> More details on what I told Linus back then:

>     https://lore.kernel.org/rust-for-linux/CANiq72kkjGVAtWNZjz5VGen4xoVLfRa+Wv399PUO=EfcA4TEfQ@mail.gmail.com/

I should be able to run rust-analyzer to verify that it doesn't error at
least, it looks like rust-analyzer unconditionally outputs into the
current source tree, but it is just one specific file so it's less of an
issue than random cruft.

Running rusttest is a bit weird in that it requires a kernel config but
seems to work fine so I can do that, I was already planning to run KUnit:

|   RUSTC T  /home/broonie/git/linux/rust/macros/lib.rs
| 
| running 0 tests
|
| test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
|   RUSTDOC T /home/broonie/git/linux/rust/macros/lib.rs
|
| running 10 tests
| ii........
| test result: ok. 8 passed; 0 failed; 2 ignored; 0 measured; 0 filtered out; finished in 0.34s

The build seems rather serialised but it's not that big so not a big
deal.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)