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] [day] [month] [year] [list]

Message-ID: <CANiq72njSUPt2CvjBiNyKw1KHSgnMdcBnXNL_pHV4iURYL1n6g@mail.gmail.com>
Date: Tue, 20 Jan 2026 23:08:40 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Mark Brown <broonie@...nel.org>
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 Mon, Jan 19, 2026 at 8:05 PM Mark Brown <broonie@...nel.org> wrote:
>
> :) What I have figured out ready for deployment (I'm introducing one
> thing per day, today is kselftest) is:
>
>   ./scripts/config --file foo/.config --enable RUST
>   make LLVM=1 rustdoc rusftmt
>
> though it looks like allmodconfig has actually picked up CONFIG_RUST so
> I might just be able to add the rustdoc/fmt to that.  I might split the
> two makes for ease of reporting.

That is great, thanks!

`rustfmt` + `rustdoc` already cover the most important bits, indeed. I
definitely recommend separating them.

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

Apart from those, the other main one is adding `CLIPPY=1` to your main
`make` line (i.e. not as a new line or command, but in the normal
build one -- the reason is it would otherwise rebuild all the Rust
code constantly if you set/unset it back and forth).

`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.

There are others, but they are not really important compared to that one.

More details on what I told Linus back then:

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

Thanks Mark!

Cheers,
Miguel