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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CABVgOS=DHdF6XmVUKH1zTML3kV7ozy8BG4o1dyd07BnngpYx4A@mail.gmail.com>
Date: Thu, 22 Jan 2026 14:36:14 +0800
From: David Gow <davidgow@...gle.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Mark Brown <broonie@...nel.org>, 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 Thu, 22 Jan 2026 at 02:55, Miguel Ojeda
<miguel.ojeda.sandonis@...il.com> wrote:
>
> On Wed, Jan 21, 2026 at 3:56 PM Mark Brown <broonie@...nel.org> wrote:

(...snnip...)

> > 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:
>
> We used the `rusttest` target more in the past, before I made the
> KUnit integration of the doctests, but it really doesn't do much
> nowadays and carries a fair bit of complexity on the build system. My
> current thinking is to migrate those tests and then just make it no-op
> until we find a better use case if any for the target name. So it
> isn't critical if you don't run it.
>
> Now, you mention KUnit, and that is very interesting!
>
> The overwhelming majority of our tests are all in fact KUnit-based,
> e.g. these are our doctests (i.e. examples that are built and ran as
> tests):
>
>     [  2.714912] # rust_doctests_kernel: pass:283 fail:0 skip:0 total:283
>
> but we also have a few other suites that come from `#[test]`s
> ("normal" unit tests), e.g.:
>
>      [  2.260774] # rust_atomics: pass:6 fail:0 skip:0 total:6
>
> So, do you mean you plan to run them under QEMU for x86_64 or arm64 or
> similar? That would be amazing for us! I didn't know you planned to do
> runtime tests.
>
> For x86_64 and arm64 things should work fine and it would be great to
> enforce it in linux-next already (I check the KUnit results in several
> trees, including stable/LTSs).
>
> Now, if you mean UML to run them, that is still best-effort with Rust,
> and it may or may not be completely clean at certain moments (Cc'ing
> David, who has been driving that and done a ton of work there).

The UML Rust support is pretty stable for the core Rust bits, KUnit
tests, etc. It can get a little broken from time to time with new
drivers, gcc-based builds (instead of LLVM=1), or 32-bit builds.
Ideally, those will work as well --- everything seems fine at the
moment --- and you shouldn't have any problems with just running:

./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_RUST=y
--make_options LLVM=1

But do let me know if anything is broken.

Cheers,
-- David

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5281 bytes)