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

[Andy Shevchenko]

On Thu, Nov 12, 2026 at 02:42:40PM -0700, Nathan Chancellor wrote:
> 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?

No, I can easily reproduce that on v7.4-rcX.

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

Thanks, this indeed helps. But I prefer not to remember this type of hacks.

-- 
With Best Regards,
Andy Shevchenko

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

Re: rant on Rust in kernel

[Andy Shevchenko]

On Thu, Nov 12, 2026 at 10:59:21PM +0100, Miguel Ojeda wrote:
> 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.
>   ***

Yes, indeed. Any idea what to do (see below)?

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

Ah, it seems I was mistaken, the distro is Debian trixie which sounds like stable.
Unstable is on my desktop.

> > 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?

It works what he suggested as a workaround.

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

-- 
With Best Regards,
Andy Shevchenko

Re: rant on Rust in kernel

[Miguel Ojeda]

On Fri, Nov 13, 2026 at 5:44 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> Yes, indeed. Any idea what to do (see below)?
>
> Ah, it seems I was mistaken, the distro is Debian trixie which sounds like stable.
> Unstable is on my desktop.

If you want to build with Rust enabled, then you need to either change
LLVM or `bindgen` to fit the equation above.

So, for instance, you could build with an older LLVM (e.g. LLVM 19 is
the default one in Debian stable). If LLVM 22 is around you may need
to use `LIBCLANG_PATH` to point to an older one.

Or, if you want to use LLVM 22, then you could install the `bindgen`
from Debian testing or unstable (they have 0.72.1, which is new enough
for LLVM 22, and checking in a Debian trixie container the build
succeeds).

Or you could build yourself a `bindgen` from scratch:

  cargo install --locked bindgen-cli

That is the easiest route, and takes just about a minute to build, but
requires trusting something else than your distribution. If you do,
you can use `make BINDGEN=...` to point to it, or you can just put it
in your `$PATH`.

I hope that helps.

Cheers,
Miguel