rust: bump minimum Rust and `bindgen` versions

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version.

Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1).

Debian Trixie's release happened on 2025-08-09 [4], which means that a fair amount of time has passed since its release for kernel developers to upgrade.

Thus bump the minimum to the new version.

Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us.

pin-init was left as-is since the patches come from upstream. And the vendored crates are unmodified, since we do not want to change those.

Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the Rust upstream binaries use LLVM 19.1.7), thus e.g. RUSTC_LLVM_VERSION tests can also be updated, but there are no suitable ones to simplify.

Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also provide versioned packages with a Rust 1.85.1 toolchain even back to Ubuntu 22.04 LTS [6].

Link https://lwn.net/Articles/1050174/ [1]

Link https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]

Link https://packages.debian.org/trixie/rustc [3]

Link https://www.debian.org/releases/trixie/ [4]

Link https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]

Link https://launchpad.net/ubuntu/+source/rustc-1.85 [6]

Signed-off-by Miguel Ojeda <[email protected]>

Debian really *should* pick up 1.85.1. It contains bugfixes serious enough that the Rust team decided it was reasonble to release a point release.

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version.

Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1).

Debian Trixie's release happened on 2025-08-09 [4], which means that a fair amount of time has passed since its release for kernel developers to upgrade.

Thus bump the minimum to the new version.

Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us.

pin-init was left as-is since the patches come from upstream. And the vendored crates are unmodified, since we do not want to change those.

Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the Rust upstream binaries use LLVM 19.1.7), thus e.g. RUSTC_LLVM_VERSION tests can also be updated, but there are no suitable ones to simplify.

Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also provide versioned packages with a Rust 1.85.1 toolchain even back to Ubuntu 22.04 LTS [6].

Link https://lwn.net/Articles/1050174/ [1]

Link https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]

Link https://packages.debian.org/trixie/rustc [3]

Link https://www.debian.org/releases/trixie/ [4]

Link https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]

Link https://launchpad.net/ubuntu/+source/rustc-1.85 [6]

Signed-off-by Miguel Ojeda <[email protected]>

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version.

Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1).

Debian Trixie's release happened on 2025-08-09 [4], which means that a fair amount of time has passed since its release for kernel developers to upgrade.

Thus bump the minimum to the new version.

Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us.

pin-init was left as-is since the patches come from upstream. And the vendored crates are unmodified, since we do not want to change those.

Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the Rust upstream binaries use LLVM 19.1.7), thus e.g. RUSTC_LLVM_VERSION tests can also be updated, but there are no suitable ones to simplify.

Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also provide versioned packages with a Rust 1.85.1 toolchain even back to Ubuntu 22.04 LTS [6].

Link https://lwn.net/Articles/1050174/ [1]

Link https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]

Link https://packages.debian.org/trixie/rustc [3]

Link https://www.debian.org/releases/trixie/ [4]

Link https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]

Link https://launchpad.net/ubuntu/+source/rustc-1.85 [6]

Signed-off-by Miguel Ojeda <[email protected]>

---
 Documentation/process/changes.rst | 2 +-
 scripts/min-tool-version.sh       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Documentation/process/changes.rst +1 -1

@@ -31,7 +31,7 @@ you probably needn't concern yourself with pcmciautils.
 ====================== ===============  ========================================
 GNU C                  8.1              gcc --version
 Clang/LLVM (optional)  15.0.0           clang --version
-Rust (optional)        1.78.0           rustc --version
+Rust (optional)        1.85.0           rustc --version
 bindgen (optional)     0.65.1           bindgen --version
 GNU make               4.0              make --version
 bash                   4.2              bash --version

scripts/min-tool-version.sh +1 -1

index 99b5575c1ef7..a270ec761f64 100755
@@ -31,7 +31,7 @@ llvm)
 	fi
 	;;
 rustc)
-	echo 1.78.0
+	echo 1.85.0
 	;;
 bindgen)
 	echo 0.65.1

This diff fails to apply on linux-next, due to conflict with ece7e57afd51 ("docs: changes.rst and ver_linux: sort the lists").

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version.

Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1).

Debian Trixie's release happened on 2025-08-09 [4], which means that a fair amount of time has passed since its release for kernel developers to upgrade.

Thus bump the minimum to the new version.

Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us.

pin-init was left as-is since the patches come from upstream. And the vendored crates are unmodified, since we do not want to change those.

Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the Rust upstream binaries use LLVM 19.1.7), thus e.g. RUSTC_LLVM_VERSION tests can also be updated, but there are no suitable ones to simplify.

Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also provide versioned packages with a Rust 1.85.1 toolchain even back to Ubuntu 22.04 LTS [6].

Link https://lwn.net/Articles/1050174/ [1]

Link https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]

Link https://packages.debian.org/trixie/rustc [3]

Link https://www.debian.org/releases/trixie/ [4]

Link https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]

Link https://launchpad.net/ubuntu/+source/rustc-1.85 [6]

Signed-off-by Miguel Ojeda <[email protected]>

---
 Documentation/process/changes.rst | 2 +-
 scripts/min-tool-version.sh       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version.

Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1).

[...]

Following the Rust compiler bump, we can now update Clippy's MSRV we set in the configuration, which will improve the diagnostics it generates.

Thus do so and clean a few of the allows that are not needed anymore.

Signed-off-by Miguel Ojeda <[email protected]>

---
 .clippy.toml                      | 2 +-
 drivers/gpu/nova-core/gsp/cmdq.rs | 6 +-----
 rust/kernel/ptr.rs                | 1 -
 rust/kernel/transmute.rs          | 2 --
 4 files changed, 2 insertions(+), 9 deletions(-)

 drivers/gpu/nova-core/gsp/cmdq.rs | 6 +-----

Following the Rust compiler bump, we can now update Clippy's MSRV we set in the configuration, which will improve the diagnostics it generates.

Thus do so and clean a few of the allows that are not needed anymore.

With the Rust version bump in place, several Kconfig conditions based on RUSTC_VERSION are always true.

Thus simplify them.

The minimum supported major LLVM version by our new Rust minimum version is now LLVM 18, instead of LLVM 16. However, there are no possible cleanups for RUSTC_LLVM_VERSION.

Signed-off-by Miguel Ojeda <[email protected]>

---
 arch/Kconfig       | 3 +--
 arch/arm64/Kconfig | 8 --------
 arch/riscv/Kconfig | 3 ---
 init/Kconfig       | 2 --
 4 files changed, 1 insertion(+), 15 deletions(-)

With the Rust version bump in place, several Kconfig conditions based on RUSTC_VERSION are always true.

Thus simplify them.

The minimum supported major LLVM version by our new Rust minimum version is now LLVM 18, instead of LLVM 16. However, there are no possible cleanups for RUSTC_LLVM_VERSION.

[...]

With the Rust version bump in place, the RUSTC_HAS_SLICE_AS_FLATTENED Kconfig (automatic) option is always true.

Thus remove the option and simplify the code.

In particular, this includes removing the slice module which contained the temporary slice helpers, i.e. the AsFlattened extension trait and its impls.

Signed-off-by Miguel Ojeda <[email protected]>

---
 init/Kconfig           |  3 ---
 rust/kernel/lib.rs     |  1 -
 rust/kernel/prelude.rs |  3 ---
 rust/kernel/slice.rs   | 49 ------------------------------------------
 4 files changed, 56 deletions(-)
 delete mode 100644 rust/kernel/slice.rs

With the Rust version bump in place, the RUSTC_HAS_SLICE_AS_FLATTENED Kconfig (automatic) option is always true.

Thus remove the option and simplify the code.

In particular, this includes removing the slice module which contained the temporary slice helpers, i.e. the AsFlattened extension trait and its impls.

[...]

With the Rust version bump in place, the RUSTC_HAS_COERCE_POINTEE Kconfig (automatic) option is always true.

Thus remove the option and simplify the code.

In particular, this includes removing our use of the predecessor unstable features we used with Rust < 1.84.0 (coerce_unsized, dispatch_from_dyn and unsize).

Signed-off-by Miguel Ojeda <[email protected]>

---
 init/Kconfig              |  3 ---
 rust/kernel/alloc/kbox.rs | 29 ++---------------------------
 rust/kernel/lib.rs        |  8 +-------
 rust/kernel/list/arc.rs   | 22 +---------------------
 rust/kernel/sync/arc.rs   | 21 ++-------------------
 5 files changed, 6 insertions(+), 77 deletions(-)

 rust/kernel/alloc/kbox.rs | 29 ++---------------------------

With the Rust version bump in place, the RUSTC_HAS_COERCE_POINTEE Kconfig (automatic) option is always true.

Thus remove the option and simplify the code.

In particular, this includes removing our use of the predecessor unstable features we used with Rust < 1.84.0 (coerce_unsized, dispatch_from_dyn and unsize).

[...]

Back in Rust 1.82.0, I cleaned the rustdoc::unescaped_backticks lint in upstream Rust and added tests so that hopefully it would not regress [1].

Thus we can remove it from our side given the Rust minimum version bump.

Link https://github.com/rust-lang/rust/pull/128307 [1]

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/Makefile | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

Back in Rust 1.82.0, I cleaned the rustdoc::unescaped_backticks lint in upstream Rust and added tests so that hopefully it would not regress [1].

Thus we can remove it from our side given the Rust minimum version bump.

Now that the Rust minimum version is 1.85.0, there is no need to enable certain features that are stable.

Thus clean them up.

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/Makefile          |  2 --
 rust/kernel/lib.rs     | 21 ---------------------
 scripts/Makefile.build |  6 +-----
 3 files changed, 1 insertion(+), 28 deletions(-)

Now that the Rust minimum version is 1.85.0, there is no need to enable certain features that are stable.

Thus clean them up.

With the minimum version bump in place, rustdoc now always recognizes the --remap-path-prefix flag.

In addition, the Internal Compiler Error that the comment mentions [1] was fixed in Rust 1.87.0 [2], so we still need to skip the flag for the normal rustdoc case, but not for --test since the ICE does not reproduce there -- please see commit 2c8725c1dca3 ("rust: kbuild: skip --remap-path-prefix for rustdoc").

Thus update the comment and remove the skipping of the flag for the --test case.

Note that commit dda135077ecc ("rust: build: remap path to avoid absolute path") re-landed the --remap-path-prefix flag (together with --remap-path-scope), so we keep the workaround, i.e. an alternative could have been to simply delete the skip entirely, but since we still have it and it will be needed when this gets merged, let's keep it.

Link https://github.com/rust-lang/rust/issues/138520 [1]

Link https://github.com/rust-lang/rust/pull/138556 [2]

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/Makefile | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

rust/Makefile +3 -4

index 193cf06eea64..708530ee3613 100644
@@ -142,10 +142,9 @@ rustdoc_modifiers_workaround := $(if $(call rustc-min-version,108800),-Cunsafe-a
 # Similarly, for doctests (https://github.com/rust-lang/rust/issues/146465).
 doctests_modifiers_workaround := $(rustdoc_modifiers_workaround)$(if $(call rustc-min-version,109100),$(comma)sanitizer)
 
-# `rustc` recognizes `--remap-path-prefix` since 1.26.0, but `rustdoc` only
-# since Rust 1.81.0. Moreover, `rustdoc` ICEs on out-of-tree builds since Rust
-# 1.82.0 (https://github.com/rust-lang/rust/issues/138520). Thus workaround both
-# issues skipping the flag. The former also applies to `RUSTDOC TK`.
+# `rustdoc` ICEs on out-of-tree builds in Rust < 1.87.0
+# (https://github.com/rust-lang/rust/issues/138520). Thus workaround the
+# issue skipping the flag.
 quiet_cmd_rustdoc = RUSTDOC $(if $(rustdoc_host),H, ) $<
       cmd_rustdoc = \
 	OBJTREE=$(abspath $(objtree)) \

rust/Makefile +1 -0

+	$(RUSTDOC) --test $(rust_flags) \
 		-L$(objtree)/$(obj) --extern ffi --extern pin_init \
 		--extern kernel --extern build_error --extern macros \
 		--extern bindings --extern uapi \

I'm not sure that I parse this. You do remove the filter-out completely below?

Looks like this is going to conflict with rust-fixes (which adds the --remap-path-scope). Perhaps worth doing a back merge?

[...]

Note that commit dda135077ecc ("rust: build: remap path to avoid absolute path") re-landed the --remap-path-prefix flag (together with --remap-path-scope), so we keep the workaround, i.e. an alternative could have been to simply delete the skip entirely, but since we still have it and it will be needed when this gets merged, let's keep it.

rust/Makefile +0 -0

index 193cf06eea64..708530ee3613 100644

The Internal Compiler Error that the comment mentions [1] was fixed in Rust 1.87.0 [2]. And, for other workarounds, we plan on limiting where we apply them [3].

Thus limit the ICE one too.

This will help to make sure the workaround is not needed anymore on newer versions.

Link https://github.com/rust-lang/rust/issues/138520 [1]

Link https://github.com/rust-lang/rust/pull/138556 [2]

Link https://lore.kernel.org/rust-for-linux/[email protected]/ [3] open here

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

rust/Makefile +0 -0

index 708530ee3613..163d2258e93f 100644

rust/Makefile +2 -1

+
 quiet_cmd_rustdoc = RUSTDOC $(if $(rustdoc_host),H, ) $<
       cmd_rustdoc = \
 	OBJTREE=$(abspath $(objtree)) \
-	$(RUSTDOC) $(filter-out $(skip_flags) --remap-path-prefix=%,$(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \
+	$(RUSTDOC) $(filter-out $(skip_flags) $(rustdoc_remap_workaround),$(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \
 		$(rustc_target_flags) -L$(objtree)/$(obj) \
 		-Zunstable-options --generate-link-to-definition \
 		--output $(rustdoc_output) \

Okay, I see what the comments mean now. Perhaps squash this to the previous commit?

The Internal Compiler Error that the comment mentions [1] was fixed in Rust 1.87.0 [2]. And, for other workarounds, we plan on limiting where we apply them [3].

Thus limit the ICE one too.

This will help to make sure the workaround is not needed anymore on newer versions.

[...]

feature(split_at_checked) [1] has been stabilized in Rust 1.80.0 [2], which is beyond our new minimum Rust version (Rust 1.85.0).

Thus simplify the code using split_at_*checked().

Link https://github.com/rust-lang/rust/issues/119128 [1]

Link https://github.com/rust-lang/rust/pull/124678 [2]

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/kernel/transmute.rs | 33 ++++++---------------------------
 1 file changed, 6 insertions(+), 27 deletions(-)

feature(split_at_checked) [1] has been stabilized in Rust 1.80.0 [2], which is beyond our new minimum Rust version (Rust 1.85.0).

"beyond" is probably not the right word here?

Currently we need to go through raw pointers and then re-create the NonNull from the result of offsetting the raw pointer.

Thus, now that we bump the Rust minimum version, simplify using NonNull::add() and clean the TODO note.

Signed-off-by Miguel Ojeda <[email protected]>

Currently we need to go through raw pointers and then re-create the NonNull from the result of offsetting the raw pointer.

Thus, now that we bump the Rust minimum version, simplify using NonNull::add() and clean the TODO note.

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/kernel/alloc/allocator/iter.rs | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

Currently we need to go through raw pointers and then re-create the NonNull from the result of offsetting the raw pointer.

Thus, now that we bump the Rust minimum version, simplify using NonNull::add() and clean the TODO note.

This description is inconsistent with the previous one which had citations for both the feature (function in this case) and the feature in which it became stable (available in this case). I don't prefer either style in particular, just that things are consistent.

feature(extract_if) was stabilized in Rust 1.87.0 [1].

Thus update the comment to reflect that.

Alternatively, we could use it unstably already.

Link https://github.com/rust-lang/rust/pull/137109 [1]

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/macros/kunit.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

rust/macros/kunit.rs +0 -0

index 6be880d634e2..6f6d746b8dbb 100644

When I write the comment the intention is to enable the unstable feature and switch.

feature(extract_if) was stabilized in Rust 1.87.0 [1].

Thus update the comment to reflect that.

Alternatively, we could use it unstably already.

feature(const_refs_to_static) was stabilized in Rust 1.83.0 [1].

Thus update the comment to reflect that.

Link https://github.com/rust-lang/rust/pull/129759 [1]

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/kernel/block/mq/gen_disk.rs | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

rust/kernel/block/mq/gen_disk.rs pub fn build<T: Operations>( · line 143

Quoted 12 lines · Miguel Ojeda

rust/kernel/block/mq/gen_disk.rs +1 -3

index c8b0ecb17082..912cb805caf5 100644
@@ -140,9 +140,7 @@ pub fn build<T: Operations>(
             devnode: None,
             alternative_gpt_sector: None,
             get_unique_id: None,
-            // TODO: Set to THIS_MODULE. Waiting for const_refs_to_static feature to
-            // be merged (unstable in rustc 1.78 which is staged for linux 6.10)
-            // <https://github.com/rust-lang/rust/issues/119618>
+            // TODO: Set to `THIS_MODULE`.

Good first issue?

Reviewed-by Tamir Duberstein <[email protected]>

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's bindgen versions as our minimum supported version.

Debian Trixie was released with bindgen 0.71.1, which it still uses to this day [2].

Debian Trixie's release happened on 2025-08-09 [3], which means that a fair amount of time has passed since its release for kernel developers to upgrade.

Thus bump the minimum to the new version.

Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us.

Ubuntu 25.10 also has a recent enough bindgen [4] (even the already unsupported Ubuntu 25.04 had it), and they also provide versioned packages with bindgen 0.71.1 back to Ubuntu 24.04 LTS [5].

Link https://lwn.net/Articles/1050174/ [1]

Link https://packages.debian.org/trixie/bindgen [2]

Link https://www.debian.org/releases/trixie/ [3]

Link https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [4]

Link https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [5]

Signed-off-by Miguel Ojeda <[email protected]>

---
 Documentation/process/changes.rst | 2 +-
 scripts/min-tool-version.sh       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's bindgen versions as our minimum supported version.

Debian Trixie was released with bindgen 0.71.1, which it still uses to this day [2].

[...]

It is not possible anymore to fall into the issue that this warning was alerting about given the bindgen version bump.

Thus simplify by removing the machinery behind it, including tests.

Signed-off-by Miguel Ojeda <[email protected]>

---
 scripts/rust_is_available.sh             | 13 ------------
 scripts/rust_is_available_bindgen_0_66.h |  2 --
 scripts/rust_is_available_test.py        | 26 +++---------------------
 3 files changed, 3 insertions(+), 38 deletions(-)
 delete mode 100644 scripts/rust_is_available_bindgen_0_66.h

scripts/rust_is_available.sh +0 -13

index d2323de0692c..77896e31dab5 100755
@@ -163,19 +163,6 @@ if [ "$rust_bindings_generator_cversion" -lt "$rust_bindings_generator_min_cvers
 	echo >&2 "***"
 	exit 1
 fi
-if [ "$rust_bindings_generator_cversion" -eq 6600 ] ||
-	[ "$rust_bindings_generator_cversion" -eq 6601 ]; then
-	# Distributions may have patched the issue (e.g. Debian did).
-	if ! "$BINDGEN" $(dirname $0)/rust_is_available_bindgen_0_66.h >/dev/null; then
-		echo >&2 "***"
-		echo >&2 "*** Rust bindings generator '$BINDGEN' versions 0.66.0 and 0.66.1 may not"
-		echo >&2 "*** work due to a bug (https://github.com/rust-lang/rust-bindgen/pull/2567),"
-		echo >&2 "*** unless patched (like Debian's)."
-		echo >&2 "***   Your version:     $rust_bindings_generator_version"
-		echo >&2 "***"
-		warning=1
-	fi
-fi
 
 # Check that the `libclang` used by the Rust bindings generator is suitable.
 #

scripts/rust_is_available_bindgen_0_66.h deleted +0 -2

deleted file mode 100644
index c0431293421c..000000000000
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#define A "\0"

scripts/rust_is_available_test.py +3 -23

index 4fcc319dea84..b66fa5933844 100755
@@ -54,17 +54,12 @@ else:
 """)
 
     @classmethod
-    def generate_bindgen(cls, version_stdout, libclang_stderr, version_0_66_patched=False, libclang_concat_patched=False):
+    def generate_bindgen(cls, version_stdout, libclang_stderr, libclang_concat_patched=False):
         if libclang_stderr is None:
             libclang_case = f"raise SystemExit({cls.bindgen_default_bindgen_libclang_failure_exit_code})"
         else:
             libclang_case = f"print({repr(libclang_stderr)}, file=sys.stderr)"
 
-        if version_0_66_patched:
-            version_0_66_case = "pass"
-        else:
-            version_0_66_case = "raise SystemExit(1)"
-
         if libclang_concat_patched:
             libclang_concat_case = "print('pub static mut foofoo: ::std::os::raw::c_int;')"
         else:

@@ -74,8 +69,6 @@ else:
 import sys
 if "rust_is_available_bindgen_libclang.h" in " ".join(sys.argv):
     {libclang_case}
-elif "rust_is_available_bindgen_0_66.h" in " ".join(sys.argv):
-    {version_0_66_case}
 elif "rust_is_available_bindgen_libclang_concat.h" in " ".join(sys.argv):
     {libclang_concat_case}
 else:

@@ -83,8 +76,8 @@ else:
 """)
 
     @classmethod
-    def generate_bindgen_version(cls, stdout, version_0_66_patched=False):
-        return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr, version_0_66_patched)
+    def generate_bindgen_version(cls, stdout):
+        return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr)
 
     @classmethod
     def generate_bindgen_libclang_failure(cls):

@@ -245,19 +238,6 @@ else:
         result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
         self.assertIn(f"Rust bindings generator '{bindgen}' is too old.", result.stderr)
 
-    def test_bindgen_bad_version_0_66_0_and_0_66_1(self):
-        for version in ("0.66.0", "0.66.1"):
-            with self.subTest(version=version):
-                bindgen = self.generate_bindgen_version(f"bindgen {version}")
-                result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
-                self.assertIn(f"Rust bindings generator '{bindgen}' versions 0.66.0 and 0.66.1 may not", result.stderr)
-
-    def test_bindgen_bad_version_0_66_0_and_0_66_1_patched(self):
-        for version in ("0.66.0", "0.66.1"):
-            with self.subTest(version=version):
-                bindgen = self.generate_bindgen_version(f"bindgen {version}", True)
-                result = self.run_script(self.Expected.SUCCESS, { "BINDGEN": bindgen })
-
     def test_bindgen_libclang_failure(self):
         bindgen = self.generate_bindgen_libclang_failure()
         result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })

The scripts/rust_is_available.sh change looks correct to me, although I couldn't get scripts/rust_is_available_test.py to run on NixOS.

Looks like it filtered out PATH but uses /usr/bin/env to find python binary? For obvious reasons that will only work if python is located /usr/bin/python.

It is not possible anymore to fall into the issue that this warning was alerting about given the bindgen version bump.

Thus simplify by removing the machinery behind it, including tests.

It is not possible anymore to fall into the issue that this warning was alerting about given the bindgen version bump.

Thus simplify by removing the machinery behind it, including tests.

As the comment in the Makefile explains, previously, we needed to limit ourselves to the list of Rust versions known by bindgen for its --rust-target option.

In other words, we needed to consult the versions known by the minimum version of bindgen that we supported.

Now that we bumped the minimum version of bindgen, that limitation does not apply anymore.

Thus replace the comment and simply write our minimum supported Rust version there, which is much simpler.

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/Makefile | 16 ++--------------
 1 file changed, 2 insertions(+), 14 deletions(-)

As the comment in the Makefile explains, previously, we needed to limit ourselves to the list of Rust versions known by bindgen for its --rust-target option.

In other words, we needed to consult the versions known by the minimum version of bindgen that we supported.

Now that we bumped the minimum version of bindgen, that limitation does not apply anymore.

Some citations pointing to the upstream changes would be good.

Until the version bump of bindgen, we needed to pass a dummy parameter to avoid failing the --version call.

Thus remove it.

Signed-off-by Miguel Ojeda <[email protected]>

---
 init/Kconfig                 | 7 +------
 scripts/rust_is_available.sh | 8 +-------
 2 files changed, 2 insertions(+), 13 deletions(-)

Until the version bump of bindgen, we needed to pass a dummy parameter to avoid failing the --version call.

Thus remove it.

There is a workaround that has not been needed, even already after commit 08ab786556ff ("rust: bindgen: upgrade to 0.65.1"), but it does not hurt.

Thus remove it.

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/bindgen_parameters | 4 ----
 1 file changed, 4 deletions(-)

There is a workaround that has not been needed, even already after commit 08ab786556ff ("rust: bindgen: upgrade to 0.65.1"), but it does not hurt.

Thus remove it.

The issue that required allows for cfg(test) code generated by bindgen for layout testing was fixed back in bindgen 0.60.0 [1], so it could have been removed even before the version bump, but it does not hurt.

Thus remove it now.

Link https://github.com/rust-lang/rust-bindgen/pull/2203 [1]

Signed-off-by Miguel Ojeda <[email protected]>

---
 rust/bindings/lib.rs | 4 ----
 rust/uapi/lib.rs     | 4 ----
 2 files changed, 8 deletions(-)

The issue that required allows for cfg(test) code generated by bindgen for layout testing was fixed back in bindgen 0.60.0 [1], so it could have been removed even before the version bump, but it does not hurt.

How about ordering this, the previous patch, and the next patch ahead of the version bump to avoid the need to mention it here?

These were likely copied from the bindings and uapi crates, but are unneeded since there are no cfg(test)s in the bindings.

In addition, the issue that triggered the addition in those crates originally is also fixed in bindgen (please see the previous commit).

Thus remove them.

Signed-off-by Miguel Ojeda <[email protected]>

These were likely copied from the bindings and uapi crates, but are unneeded since there are no cfg(test)s in the bindings.

In addition, the issue that triggered the addition in those crates originally is also fixed in bindgen (please see the previous commit).

Thus remove them.

Signed-off-by Miguel Ojeda <[email protected]>

---
 drivers/gpu/nova-core/gsp/fw/r570_144.rs | 3 ---

 1 file changed, 3 deletions(-)

These were likely copied from the bindings and uapi crates, but are unneeded since there are no cfg(test)s in the bindings.

In addition, the issue that triggered the addition in those crates originally is also fixed in bindgen (please see the previous commit).

Thus remove them.

[...]

Both openSUSE Tumbleweed and Slowroll provide the rust-src package nowadays [1].

Thus remove the version-specific one from the Quick Start guide.

Now that the minimum supported Rust version is bumped, bump the versioned Rust packages [1][2][3][4] to that version for Ubuntu in the Quick Start guide.

In addition, add "may" to the RUST_LIB_SRC line since it does not look like it is needed from a quick test in a Ubuntu 24.04 LTS container.

RUST_LIB_SRC is also mentioned in the nix section, do you know if it is still needed there?

Quoted 3 lines · Tamir Duberstein

RUST_LIB_SRC is also mentioned in the nix section, do you know if it is still needed there?

Yeah, that would be nice to know.

I tried on my own, and it does seem still required (at least with those packages mentioned in the example). But perhaps a Nix user knows of a better way to do it, anyway.

So I kept it.

By the way, I think it would be nice to have a "standard", well-maintained shell.nix (or a flake or whatever is best nowadays) in the kernel tree somewhere, i.e. one that is known to work, that covers most tooling used in the kernel, etc.

Cheers,
Miguel

It's still required.

Perhaps having a repo in rust-for-linux GitHub org (or somewhere else in kernel.org SCM) where we can point people to?

Ubuntu 25.04 is out of support [1], and Ubuntu 25.10 is the latest supported one.

Moreover, Ubuntu 25.10 is the first that provides a recent enough Rust given the minimum bump -- they provide 1.85.1 [2].

Thus update it.

[...]

Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu 25.10 has [2][3].

We could update the title and the paragraph, but to simplify and to make it more consistent with the other distributions' sections, let's instead just remove that title. It will also reduce the differences later on to keep it updated. Eventually, when we remove the remaining subsection for older LTSs, Ubuntu should be a small section like the other distributions.

[...]

Gentoo does not need the "testing" note, since its packages are recent enough even in the stable branch [1][2].

Thus remove it to simplify the documentation.

Nix does not need the "unstable channel" note, since its packages are recent enough even in the stable channel [1][2].

Thus remove it to simplify the documentation.

Link https://search.nixos.org/packages?channel=25.11&query=rust [1]

Link https://search.nixos.org/packages?channel=25.11&query=bindgen [2]

Signed-off-by Miguel Ojeda <[email protected]>

---
 Documentation/rust/quick-start.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Nix does not need the "unstable channel" note, since its packages are recent enough even in the stable channel [1][2].

Thus remove it to simplify the documentation.

The versions provided nowadays by even a distribution like Debian Stable (and Debian Old Stable) are newer than those mentioned [1].

Thus remove the workaround.

Note that the minimum binutils version in the kernel is still 2.30, so one could argue part of the note is still relevant, but it is unlikely a kernel developer using such an old binutils is enabling Rust on a modern kernel, especially when using distribution toolchains, e.g. the Rust minimum version is not satisfied by Debian Old Stable.

So we are at the point where keeping the docs short and relevant for essentially everyone is probably the better trade-off.

Link https://packages.debian.org/search?suite=all&searchon=names&keywords=binutils [1]

Link https://lore.kernel.org/all/CANiq72mCpc9=2TN_zC4NeDMpFQtPXAFvyiP+gRApg2vzspPWmw@mail.gmail.com/ open here

Signed-off-by Miguel Ojeda <[email protected]>

---
 Documentation/rust/quick-start.rst | 9 ---------
 1 file changed, 9 deletions(-)

Documentation/rust/quick-start.rst +0 -9

index 5bbe059a8fa3..a6ec3fa94d33 100644
@@ -352,12 +352,3 @@ Hacking
 To dive deeper, take a look at the source code of the samples
 at ``samples/rust/``, the Rust support code under ``rust/`` and
 the ``Rust hacking`` menu under ``Kernel hacking``.
-
-If GDB/Binutils is used and Rust symbols are not getting demangled, the reason
-is the toolchain does not support Rust's new v0 mangling scheme yet.
-There are a few ways out:
-
-- Install a newer release (GDB >= 10.2, Binutils >= 2.36).
-
-- Some versions of GDB (e.g. vanilla GDB 10.1) are able to use
-  the pre-demangled names embedded in the debug info (``CONFIG_DEBUG_INFO``).

The versions provided nowadays by even a distribution like Debian Stable (and Debian Old Stable) are newer than those mentioned [1].

Thus remove the workaround.

Note that the minimum binutils version in the kernel is still 2.30, so one could argue part of the note is still relevant, but it is unlikely a kernel developer using such an old binutils is enabling Rust on a modern kernel, especially when using distribution toolchains, e.g. the Rust minimum version is not satisfied by Debian Old Stable.

[...]

There is no need to use def_bool y if <expr> -- one can simply write def_bool <expr>.

In fact, the simpler form is how we actually use them in practice in init/Kconfig.

Thus simplify the example.

Signed-off-by Miguel Ojeda <[email protected]>

---
 Documentation/rust/general-information.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

There is no need to use def_bool y if <expr> -- one can simply write def_bool <expr>.

In fact, the simpler form is how we actually use them in practice in init/Kconfig.

Thus simplify the example.

[...]

Currently the example in the documentation shows a version-based name for the Kconfig example:

    RUSTC_VERSION_MIN_107900

The reason behind it was to possibly avoid repetition in case several features used the same minimum.

However, we ended up preferring to give them a descriptive name for each feature added even if that could lead to some repetition. In practice, the repetition has not happened so far, and even if it does at some point, it is not a big deal.

Thus replace the example in the documentation with one of our current examples (after removing previous ones from the bump), to show how they actually look like, and in case someone greps for it.

In addition, it has the advantage that it shows the RUSTC_HAS_* pattern we follow in init/Kconfig, similar to the C side.

Signed-off-by Miguel Ojeda <[email protected]>

---
 Documentation/rust/general-information.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Currently the example in the documentation shows a version-based name for the Kconfig example:

    RUSTC_VERSION_MIN_107900

The reason behind it was to possibly avoid repetition in case several features used the same minimum.

[...]

From: Alice Ryhl <[email protected]>

By default bindgen will convert 'enum lru_status' into a typedef for an integer. For the most part, an integer of the same size as the enum results in the correct ABI, but in the specific case of CFI, that is not the case. The CFI encoding is supposed to be the same as a struct called 'lru_status' rather than the name of the underlying native integer type.

To fix this, tell bindgen to generate a newtype and set the CFI type explicitly. Note that we need to set the CFI attribute explicitly as bindgen is using repr(transparent), which is otherwise identical to the inner type for ABI purposes.

This allows us to remove the page range helper C function in Binder without risking a CFI failure when list_lru_walk calls the provided function pointer.

The --with-attribute-custom-enum argument requires bindgen v0.71 or greater.

[ In particular, the feature was added in 0.71.0 [1][2].

In addition, feature(cfi_encoding) has been available since Rust 1.71.0 [3].

Link https://github.com/rust-lang/rust-bindgen/issues/2520 [1]

Link https://github.com/rust-lang/rust-bindgen/pull/2866 [2]

Link https://github.com/rust-lang/rust/pull/105452 [3]

- Miguel ]

My testing procedure was to add this to the android17-6.18 branch and verify that rust_shrink_free_page is successfully called without crash, and verify that it does in fact crash when the cfi_encoding is set to other values. Note that I couldn't test this on android16-6.12 as that branch uses a bindgen version that is too old.

Signed-off-by Alice Ryhl <[email protected]>

Link https://patch.msgid.link/[email protected] open here

[ Rebased on top of the minimum Rust version bump series which provide
the required bindgen version. - Miguel ]

Signed-off-by Miguel Ojeda <[email protected]>

---
 drivers/android/binder/Makefile            |  3 +--
 drivers/android/binder/page_range.rs       |  6 +++---
 drivers/android/binder/page_range_helper.c | 24 ----------------------
 drivers/android/binder/page_range_helper.h | 15 --------------
 rust/bindgen_parameters                    |  4 ++++
 rust/bindings/bindings_helper.h            |  1 -
 rust/bindings/lib.rs                       |  1 +
 rust/uapi/lib.rs                           |  1 +
 8 files changed, 10 insertions(+), 45 deletions(-)
 delete mode 100644 drivers/android/binder/page_range_helper.c
 delete mode 100644 drivers/android/binder/page_range_helper.h

Sometimes it is useful to gate global Rust flags per compiler version. For instance, we may want to disable a lint that has false positives in a single version [1].

We already had helpers like rustc-min-version for that, which we use elsewhere, but we cannot currently use them for rust_common_flags, which contains the global flags for all Rust code (kernel and host), because rustc-min-version depends on CONFIG_RUSTC_VERSION, which does not exist when rust_common_flags is defined.

Thus, to support that, introduce rust_common_flags_per_version, defined after the include/config/auto.conf inclusion (where CONFIG_RUSTC_VERSION becomes available), and append it to rust_common_flags, KBUILD_HOSTRUSTFLAGS and KBUILD_RUSTFLAGS.

An alternative is moving all those three down, but that would mean separating them from the other KBUILD_* variables.

Link https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1] open here

Link https://patch.msgid.link/[email protected] open here

Signed-off-by Miguel Ojeda <[email protected]>

---
 Makefile | 8 ++++++++
 1 file changed, 8 insertions(+)

Makefile +8 -0

index 1a219bf1c771..20c8179d96ee 100644
@@ -834,6 +834,14 @@ endif # CONFIG_TRACEPOINTS
 
 export WARN_ON_UNUSED_TRACEPOINTS
 
+# Per-version Rust flags. These are like `rust_common_flags`, but may
+# depend on the Rust compiler version (e.g. using `rustc-min-version`).
+rust_common_flags_per_version :=
+
+rust_common_flags += $(rust_common_flags_per_version)
+KBUILD_HOSTRUSTFLAGS += $(rust_common_flags_per_version)
+KBUILD_RUSTFLAGS += $(rust_common_flags_per_version)
+
 include $(srctree)/arch/$(SRCARCH)/Makefile
 
 ifdef need-config

I think I would prefer moving these down.

The current approach append the flags to all variables, which will cause the following equivalence to stop holding after the flag update.

KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
                        -Zallow-features= $(HOSTRUSTFLAGS)

(Per version flags doesn't go before -O anymore, it comes after HOSTRUSTFLAGS).

Quoted 10 lines · Gary Guo

I think I would prefer moving these down.

The current approach append the flags to all variables, which will cause the following equivalence to stop holding after the flag update.

KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
                        -Zallow-features= $(HOSTRUSTFLAGS)

(Per version flags doesn't go before -O anymore, it comes after HOSTRUSTFLAGS).

[ For context for others, Sashiko reported the same and we also talked about it in a Rust for Linux call. ]

I have been thinking about this, and about potential other ways to achieve the same thing. I think the best at the moment is to move just the $(HOSTRUSTFLAGS) below, but not the rest.

The reason is that it is closer to what we do with other user (kernel) flags (e.g. arch flags come after the general ones). But I am wondering if we should/could set all the user variables later in the Makefile in general HOST*FLAGS later in the Makefile.

In fact, there is already a limitation with the host flags: -Werror, i.e. that one gets appended later, and so users cannot override it.

[...]

Anyway, for now I moved the expansion of HOSTRUSTFLAGS in v2. If Kbuild (Nathan, Nicolas) think it is a good idea to do one of the bigger changes (e.g. for more HOST* flags, appending it even later), then we can do it afterwards.

Cheers,
Miguel

[...]
defined after the include/config/auto.conf inclusion (where CONFIG_RUSTC_VERSION becomes available), and append it to rust_common_flags, KBUILD_HOSTRUSTFLAGS and KBUILD_RUSTFLAGS.

An alternative is moving all those three down, but that would mean separating them from the other KBUILD_* variables.

The Clippy precedence lint was extended in Rust 1.85.0 to include bitmasking and shift operations [1]. However, because it generated many hits, in Rust 1.86.0 it was split into a new precedence_bits lint which is not enabled by default [2].

In other words, only Rust 1.85 has a different behavior. For instance, it reports:

    warning: operator precedence can trip the unwary
      --> drivers/gpu/nova-core/fb/hal/ga100.rs:16:5
       |
    16 | /     u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT
    17 | |         | u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
    18 | |             << FLUSH_SYSMEM_ADDR_SHIFT_HI
       | |_________________________________________^
       |
       = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
       = note: `-W clippy::precedence` implied by `-W clippy::all`
       = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`
    help: consider parenthesizing your expression
       |
    16 ~     (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT) | (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
    17 +             << FLUSH_SYSMEM_ADDR_SHIFT_HI)
       |

    warning: operator precedence can trip the unwary
       --> drivers/gpu/nova-core/vbios.rs:511:17
        |
    511 | /                 u32::from(data[29]) << 24
    512 | |                     | u32::from(data[28]) << 16
    513 | |                     | u32::from(data[27]) << 8
        | |______________________________________________^
        |
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
    help: consider parenthesizing your expression
        |
    511 ~                 u32::from(data[29]) << 24
    512 +                     | u32::from(data[28]) << 16 | (u32::from(data[27]) << 8)
        |

    warning: operator precedence can trip the unwary
       --> drivers/gpu/nova-core/vbios.rs:511:17
        |
    511 | /                 u32::from(data[29]) << 24
    512 | |                     | u32::from(data[28]) << 16
        | |_______________________________________________^ help: consider parenthesizing your expression: `(u32::from(data[29]) << 24) | (u32::from(data[28]) << 16)`
        |
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence

While so far we try our best to keep all versions Clippy-clean, the minimum (which is now Rust 1.85.0 after the bump) and the latest stable are the most important ones; and this may be considered "false positives" with respect to the behavior in other versions.

Thus allow this lint for this version using the per-version flags mechanism introduced in the previous commit.

Link https://github.com/rust-lang/rust-clippy/issues/14097 [1]

Link https://github.com/rust-lang/rust-clippy/pull/14115 [2]

Signed-off-by Miguel Ojeda <[email protected]>

---
 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

The Clippy precedence lint was extended in Rust 1.85.0 to include bitmasking and shift operations [1]. However, because it generated many hits, in Rust 1.86.0 it was split into a new precedence_bits lint which is not enabled by default [2].

Might be good to retain some of this in a code comment.