rant on Rust in kernel

rant on Rust in kernel

[Andy Shevchenko]

Hi!

(Cc'ed to Rust and Kbuild people)

I have two quite annoying things that lately Rust brought to kernel
(in some way).

First of all, it broke the old and nice kernel feature to build a subset with
allmodconfig or allyesconfig. For instance,

  make LLVM=-22 O=... W=1 C=1 CF=-D__CHECK_ENDIAN__ -j64 allyesconfig -- fs/pstore/

Now this makes a very good fireworks out of some rust.

Ex.:

error[E0609]: no field `disconnect` on type `usb_driver`
  --> .../rust/kernel/usb.rs:57:27
   |
57 |             (*udrv.get()).disconnect = Some(Self::disconnect_callback);
   |                           ^^^^^^^^^^ unknown field
   |
   = note: available field is: `_address`

Second one, is that now with the above feature the build is finished like
a minute (sic!) later than it was before on a good server with 24 modern
CPU cores. It started happening somewhat a release ago.

I have no clue what is there, but I will appreciate if it gets fixed ASAP!
I rely on the above feature to save my time when doing test builds.

My repo is Linux Next based, the compilers are standard to what Debian unstable
provides. Ask me any details or help with testing any proposed patches. I'm
really disappointed of having these issues.

-- 
With Best Regards,
Andy Shevchenko

Re: rant on Rust in kernel

[Nathan Chancellor]

Hi Andy,

On Thu, Nov 12, 2026 at 05:37:11PM +0200, Andy Shevchenko wrote:
> (Cc'ed to Rust and Kbuild people)
> 
> I have two quite annoying things that lately Rust brought to kernel
> (in some way).
> 
> First of all, it broke the old and nice kernel feature to build a subset with
> allmodconfig or allyesconfig. For instance,
> 
>   make LLVM=-22 O=... W=1 C=1 CF=-D__CHECK_ENDIAN__ -j64 allyesconfig -- fs/pstore/
> 
> Now this makes a very good fireworks out of some rust.
> 
> Ex.:
> 
> error[E0609]: no field `disconnect` on type `usb_driver`
>   --> .../rust/kernel/usb.rs:57:27
>    |
> 57 |             (*udrv.get()).disconnect = Some(Self::disconnect_callback);
>    |                           ^^^^^^^^^^ unknown field
>    |
>    = note: available field is: `_address`
> 
> Second one, is that now with the above feature the build is finished like
> a minute (sic!) later than it was before on a good server with 24 modern
> CPU cores. It started happening somewhat a release ago.

You are probably seeing this behavior within the last release or so
because of

  2625480a1bf7 ("hardening: Default randstruct off with rust for better allmodconfig support")

which allows Rust to be enabled with all{mod,yes}config to make -next
testing easier.

As for that particular error, is it a -next regression?

> I have no clue what is there, but I will appreciate if it gets fixed ASAP!
> I rely on the above feature to save my time when doing test builds.

Note: The following is my understanding, Miguel or other Rust folks
might correct me.

You are noticing the face that certain Rust crates like kernel are built
in the prepare target, which will run for pretty much every build; it
has been this way since Rust has been merged, you are just noticing it
now because Rust is enabled in your configuration. I believe this was
done to ensure the kernel crate is built and available before drivers
were built via recursive make since they consume it. However, as you
have noticed, this implementation bogs down the build and the same
problem exists for Rust drivers that depend on other Rust abstractions
and such.

Miguel and I chatted about this at Plumbers and we absolutely want to
get it resolved but I am just not sure how quickly that will happen. In
the meantime, you could just use KCONFIG_ALLCONFIG to disable
CONFIG_RUST during configuration time so you can still use a single
command:

  make ... KCONFIG_ALLCONFIG=<(echo CONFIG_RUST=n) allyesconfig -- ...

-- 
Cheers,
Nathan

Re: rant on Rust in kernel

[Miguel Ojeda]

On Thu, Nov 12, 2026 at 4:37 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> First of all, it broke the old and nice kernel feature to build a subset with
> allmodconfig or allyesconfig. For instance,

> error[E0609]: no field `disconnect` on type `usb_driver`
>   --> .../rust/kernel/usb.rs:57:27

This doesn't sound related to building a subset, but rather a known
toolchain bug -- our `rustavailable` script checks for that. Are you
seeing this warning in the log when you build?

  ***
  *** Rust bindings generator 'bindgen' < 0.72.1 together with libclang >= 22
  *** may not work due to a bug
(https://github.com/rust-lang/rust-bindgen/pull/3278).
  ***   Your bindgen version:  0.71.1
  ***   Your libclang version: 22.1.8
  ***
  ***
  *** Please see Documentation/rust/quick-start.rst for details
  *** on how to set up the Rust support.
  ***

In particular, you mention Debian unstable packages: I cannot
reproduce the issue in pure Debian unstable, nor with `LLVM=-22`,
unless I also pick `bindgen` from Debian stable (rather than Debian
unstable) which is older (and then I get the warning above).

Can you confirm which toolchains are you using exactly? Ideally
checking the `CONFIG_*` values in your `.config`, e.g.
`CONFIG_BINDGEN_VERSION_TEXT`.

> Second one, is that now with the above feature the build is finished like
> a minute (sic!) later than it was before on a good server with 24 modern
> CPU cores. It started happening somewhat a release ago.

This is a bit vague, and there were some changes to the build system
recently, but I agree with Nathan: it may simply be that you got
`CONFIG_RUST` enabled.

It could still be something else, of course -- if what Nathan suggests
doesn't work, then could you please compare the kernel config file
between the "good" and the "bad" points in time you have, and/or the
build log?

If that still doesn't explain it, then could you please do a quick
bisect if it is reproducible on your side?

Cheers,
Miguel