From a5c7d35e2fd3e24c411816c91f8f6cc78e652e0c Mon Sep 17 00:00:00 2001 From: Nikolai Grlica Date: Mon, 10 Aug 2026 15:03:35 +0000 Subject: [PATCH 1/8] rust: kernel: list: fix incorrect pop_back example comment The example uses pop_back(), but the accompanying comment says pop_front(). Update the comment to match the example. Signed-off-by: Nikolai Grlica Cc: stable@vger.kernel.org Fixes: bf87a41b85d6 ("rust: list: Add an example for `ListLinksSelfPtr` usage") Link: https://patch.msgid.link/20260810150322.61809-1-nikolai@nikolaigrlica.dev Signed-off-by: Miguel Ojeda --- rust/kernel/list.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rust/kernel/list.rs b/rust/kernel/list.rs index 406e3a028c55..0f367264ee2e 100644 --- a/rust/kernel/list.rs +++ b/rust/kernel/list.rs @@ -249,7 +249,7 @@ /// assert_eq!(list.iter().count(), 3); /// } /// -/// // Pop the items from the list using `pop_front()` and verify the content. +/// // Pop the items from the list using `pop_back()` and verify the content. /// { /// assert_eq!(list.pop_back().ok_or(EINVAL)?.value.foo(), ("a", 15)); /// assert_eq!(list.pop_back().ok_or(EINVAL)?.value.foo(), ("a", 32)); From 993f235c4af49d0e912cc28abe6d733531600237 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Wed, 5 Aug 2026 16:45:24 +0200 Subject: [PATCH 2/8] objtool/rust: add one more `noreturn` Rust function When the pointer formatting series [1] is applied and KUnit tests are enabled, `objtool` would report an error with any of our supported Rust versions. For instance, with Rust 1.97.1: rust/kernel.o: error: objtool: _R..._4core3fmt7Pointer3fmtB7_() falls through to next function _R..._4core7convert5AsRefNtB5_4BStrE6as_ref() Or, with Rust 1.85.0: rust/kernel.o: error: objtool: _R..._4core3fmt7Pointer3fmtB7_() falls through to next function _R..._4core3ffi5c_str4CStrENtNtBS_3fmt7Display3fmtB7_() This happens due to calls to the `noreturn` symbol: core::str::slice_error_fail Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. [ While the series [1] mentioned above was not applied in a way that triggered this, Gary found another case [2]: I am seeing this function causing issue on my 1.85.1 -Os build, although the error message is different this time: rust/kernel.o: warning: objtool: _R..._5range9RangeFromjEE5indexCsldbe0TGTmNx_6kernel+0x1d: stack state mismatch: cfa1=4+8 cfa2=4+16 Disassembly shows that the function call before the warning location is a call to _4core3str16slice_error_fail, and objtool thought it can return (which will end up with a unbalanced stack if it does return). Thus apply it. - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf Cc: Peter Zijlstra Reported-by: Alice Ryhl Link: https://lore.kernel.org/rust-for-linux/anLxXvCKBcAVf91_@google.com/ Link: https://lore.kernel.org/rust-for-linux/20260706-hashedptr-v13-0-377a07f2f78d@kylinos.cn/ [1] Link: https://lore.kernel.org/rust-for-linux/DKS7U9UHY6XR.2JC0EBIPCI06Z@garyguo.net/ [2] Link: https://patch.msgid.link/20260805144524.233362-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda --- tools/objtool/check.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 87db9f4ed9e2..3ab5b9f1c6a4 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -195,6 +195,7 @@ static bool is_rust_noreturn(const struct symbol *func) return str_ends_with(func->name, "_4core3num20from_str_radix_panic") || str_ends_with(func->name, "_4core3num22from_ascii_radix_panic") || str_ends_with(func->name, "_4core3num28from_ascii_bytes_radix_panic") || + str_ends_with(func->name, "_4core3str16slice_error_fail") || str_ends_with(func->name, "_4core5sliceSp15copy_from_slice17len_mismatch_fail") || str_ends_with(func->name, "_4core6option13expect_failed") || str_ends_with(func->name, "_4core6option13unwrap_failed") || From dea1bf38143f8505747c19b953ef12fb809d5d77 Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori Date: Sun, 9 Aug 2026 22:48:58 +0900 Subject: [PATCH 3/8] rust: jump_label: skip arch-specific asm in `testlib` builds Running `make rusttest` with `ARCH=` set to an architecture other than the host's may fail in the future, e.g. `ARCH=arm64` on an x86_64 host: error: alignment must be a power of 2 --> rust/kernel/jump_label.rs:51:13 | 51 | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_static_branch_asm.rs")); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: instantiated into assembly here --> :3:10 | 3 | .align 3 | ^ The reason is that `rusttest` builds the kernel crate as a host library: it passes the `CONFIG_*` cfgs of the configured architecture, but not `--target`, so code generation happens for the host. `arch_static_branch!` then selects the arch-specific inline asm arm based on CONFIG_*, and the host assembler rejects it. This does not happen with the current master because `arch_static_branch!` has no user inside the kernel crate itself yet, but fix it now to avoid surprises later. Signed-off-by: FUJITA Tomonori Link: https://patch.msgid.link/20260809134858.1219036-1-tomo@flapping.org [ Reworded slightly to clarify it "may fail in the future". - Miguel ] Signed-off-by: Miguel Ojeda --- rust/kernel/jump_label.rs | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/rust/kernel/jump_label.rs b/rust/kernel/jump_label.rs index 4e974c768dbd..f54cedcb6fd5 100644 --- a/rust/kernel/jump_label.rs +++ b/rust/kernel/jump_label.rs @@ -44,6 +44,7 @@ macro_rules! static_branch_unlikely { #[macro_export] #[doc(hidden)] +#[cfg(not(testlib))] #[cfg(CONFIG_JUMP_LABEL)] macro_rules! arch_static_branch { ($key:path, $keytyp:ty, $field:ident, $branch:expr) => {'my_label: { @@ -61,6 +62,17 @@ macro_rules! arch_static_branch { }}; } +#[macro_export] +#[doc(hidden)] +#[cfg(testlib)] +#[cfg(CONFIG_JUMP_LABEL)] +macro_rules! arch_static_branch { + ($key:path, $keytyp:ty, $field:ident, $branch:expr) => { + // The asm falls through until patched, which never happens on the host. + false + }; +} + #[cfg(CONFIG_JUMP_LABEL)] pub use arch_static_branch; From 29b03d1de967a177176d12811d970cac7882afcf Mon Sep 17 00:00:00 2001 From: Gary Guo Date: Thu, 20 Aug 2026 14:57:32 +0100 Subject: [PATCH 4/8] rust: cfi: disable function merging if CFI is enabled In Rust doc tests, there is a dummy `__module_firmware_test_init` function generated by the example in `module_firmware!`'s documentation, which just returns zero. Many other documentation examples generate functions that produce zero. LKP test robot reports [1] a `Flags::zeroed` instance; my local reproduction has a `Bounded::new::<0>`. LLVM's MergeFunctionsPass incorrectly merges functions with different KCFI types, causing `__module_firmware_test_init` to be merged into one of the zero-returning functions. As module init is invoked via an indirect function call, KCFI is checked and this produces a KCFI failure. I've reported this bug to upstream LLVM [2]; in the meantime, disable function merging if CFI is enabled. No separate treatment is needed for CONFIG_RUST_INLINE_HELPERS, as Clang does not enable function merging by default. [ LLVM already has a pending PR: https://github.com/llvm/llvm-project/pull/217665 which solves the issue. In addition, I asked upstream Rust if the unstable `-Zmerge-functions=disabled` flag will remain around: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/.60-Zmerge-functions.3Ddisabled.60/ and it does indeed look like that will be the case. - Miguel ] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202608201017.100a4511-lkp@intel.com [1] Link: https://github.com/llvm/llvm-project/issues/217629 [2] Signed-off-by: Gary Guo Cc: stable@vger.kernel.org Fixes: ca627e636551 ("rust: cfi: add support for CFI_CLANG with Rust") Reviewed-by: Sami Tolvanen Link: https://patch.msgid.link/20260820135733.37121-1-gary@kernel.org [ Fixed typos as discussed. Reworded slightly for other typos. - Miguel ] Signed-off-by: Miguel Ojeda --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 130926fa592e..c2344755a1bb 100644 --- a/Makefile +++ b/Makefile @@ -1118,7 +1118,8 @@ endif ifdef CONFIG_RUST # Always pass -Zsanitizer-cfi-normalize-integers as CONFIG_RUST selects # CONFIG_CFI_ICALL_NORMALIZE_INTEGERS. - RUSTC_FLAGS_CFI := -Zsanitizer=kcfi -Zsanitizer-cfi-normalize-integers + # Disable function merging as LLVM incorrectly merges functions with different KCFI types. + RUSTC_FLAGS_CFI := -Zsanitizer=kcfi -Zsanitizer-cfi-normalize-integers -Zmerge-functions=disabled KBUILD_RUSTFLAGS += $(RUSTC_FLAGS_CFI) export RUSTC_FLAGS_CFI endif From 0bff7711c19ba05ff3b686554c5a2d503c3e9797 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Sun, 16 Aug 2026 15:32:32 +0200 Subject: [PATCH 5/8] kbuild: rust: preserve unreachable traps with inline helpers When `CONFIG_RUST_INLINE_HELPERS` is enabled, it is possible to hit `objtool` warnings like: vmlinux.o: warning: objtool: _R..._4cmdq12CommandToGsp4init() falls through to next function _R..._4core5array4iter8IntoIterRShKj3_EEEBa_() `rustc` normally emits traps for unreachable paths. However, under `CONFIG_RUST_INLINE_HELPERS=y`, `rustc` emits LLVM bitcode and Clang performs final code generation after the helper bitcode is linked, but Clang does not trap unreachable IR by default. In turn, this means `objtool` follows compiler-generated impossible Rust `enum` paths through alignment padding into the next function, resulting in fallthrough warnings. Thus pass the LLVM `trap-unreachable` option to the final Clang invocation and suppress traps immediately after `noreturn` calls, which `objtool` already recognizes as dead ends. The combination of both flags makes it match `rustc`'s behavior. Rust 1.85.0 (the minimum supported one) supports LLVM >= 18, and both flags are available in LLVM 18. Assisted-by: LLM Cc: Gary Guo Cc: Boqun Feng Cc: Alice Ryhl Cc: Matthew Maurer Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust") Acked-by: Gary Guo Link: https://patch.msgid.link/20260816133233.197500-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda --- Makefile | 10 ++++++++++ rust/Makefile | 3 ++- scripts/Makefile.build | 3 ++- 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index c2344755a1bb..960f296e4a4d 100644 --- a/Makefile +++ b/Makefile @@ -1083,6 +1083,16 @@ endif export CC_FLAGS_SCS endif +ifdef CONFIG_RUST_INLINE_HELPERS +# `rustc` normally emits traps for unreachable paths during code generation. +# With inline helpers, Clang performs code generation from the linked bitcode +# instead, so request the same behavior explicitly. Otherwise `objtool` may +# follow an impossible Rust path into the next function. +CC_FLAGS_RUST_INLINE_HELPERS := -mllvm -trap-unreachable \ + -mllvm -no-trap-after-noreturn +export CC_FLAGS_RUST_INLINE_HELPERS +endif + ifdef CONFIG_LTO_CLANG ifdef CONFIG_LTO_CLANG_FULL CC_FLAGS_LTO := -flto diff --git a/rust/Makefile b/rust/Makefile index fbe0accc51a3..f871d94f6af2 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -644,7 +644,8 @@ quiet_cmd_rustc_library = $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QUIET)) L -Zunstable-options \ $(if $(link_helper),;$(LLVM_LINK) --internalize --suppress-warnings $(patsubst %.o,%.bc,$@) \ $(obj)/helpers/helpers$(if $(part-of-module),_module).bc -o $(patsubst %.o,%.m.bc,$@); \ - $(CC) $(CLANG_FLAGS) $(KBUILD_CFLAGS) -Wno-override-module -c $(patsubst %.o,%.m.bc,$@) -o $@ \ + $(CC) $(CLANG_FLAGS) $(KBUILD_CFLAGS) \ + $(CC_FLAGS_RUST_INLINE_HELPERS) -Wno-override-module -c $(patsubst %.o,%.m.bc,$@) -o $@ \ $(cmd_ld_single)) \ $(if $(rustc_objcopy),;$(OBJCOPY) $(rustc_objcopy) $@) \ $(cmd_objtool) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index a48209591dee..0ac326e43fea 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -347,7 +347,8 @@ quiet_cmd_rustc_o_rs = $(RUSTC_OR_CLIPPY_QUIET) $(quiet_modtag) $@ cmd_rustc_o_rs = $(rust_common_cmd) --emit=$(if $(CONFIG_RUST_INLINE_HELPERS),llvm-bc=$(patsubst %.o,%.bc,$@),obj=$@) $< \ $(if $(CONFIG_RUST_INLINE_HELPERS),;$(LLVM_LINK) --internalize --suppress-warnings $(patsubst %.o,%.bc,$@) \ $(objtree)/rust/helpers/helpers$(if $(part-of-module),_module).bc -o $(patsubst %.o,%.m.bc,$@); \ - $(CC) $(CLANG_FLAGS) $(KBUILD_CFLAGS) -Wno-override-module -c $(patsubst %.o,%.m.bc,$@) -o $@ \ + $(CC) $(CLANG_FLAGS) $(KBUILD_CFLAGS) \ + $(CC_FLAGS_RUST_INLINE_HELPERS) -Wno-override-module -c $(patsubst %.o,%.m.bc,$@) -o $@ \ $(cmd_ld_single)) \ $(cmd_objtool) From 5febf432df1cfa5b25d99b54c32103fafbdd0eb9 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Sun, 16 Aug 2026 15:32:33 +0200 Subject: [PATCH 6/8] kbuild: rust: keep Rust objects out of Clang LTO with inline helpers Under `CONFIG_LTO_CLANG` + `CONFIG_RUST_INLINE_HELPERS`, one may hit `objtool` errors such as: vmlinux.o: error: objtool: _R..._3Gsp4boot+0xd6a: can't find jump dest instruction at .text._R..._3Gsp4boot+0x1dfd The reason is that in such builds, the Clang invocation that compiles the combined Rust plus helpers bitcode emits LLVM bitcode (again) -- the final code generation happens in the linker's LTO step, which the `-mllvm` trap options passed to Clang do not reach. This, in turn, means that unreachable traps are missing, and the impossible paths do not merely fallthrough to the next symbol, but past the end of their own section, since LTO builds place each function in its own section. Thus filter `CC_FLAGS_LTO` out of the Clang invocation, so that it always emits machine code directly, with the traps in place. Assisted-by: LLM Cc: Gary Guo Cc: Boqun Feng Cc: Alice Ryhl Cc: Matthew Maurer Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust") Acked-by: Gary Guo Link: https://patch.msgid.link/20260816133233.197500-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda --- rust/Makefile | 2 +- scripts/Makefile.build | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/rust/Makefile b/rust/Makefile index f871d94f6af2..3afaad4a4a3a 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -644,7 +644,7 @@ quiet_cmd_rustc_library = $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QUIET)) L -Zunstable-options \ $(if $(link_helper),;$(LLVM_LINK) --internalize --suppress-warnings $(patsubst %.o,%.bc,$@) \ $(obj)/helpers/helpers$(if $(part-of-module),_module).bc -o $(patsubst %.o,%.m.bc,$@); \ - $(CC) $(CLANG_FLAGS) $(KBUILD_CFLAGS) \ + $(CC) $(CLANG_FLAGS) $(filter-out $(CC_FLAGS_LTO),$(KBUILD_CFLAGS)) \ $(CC_FLAGS_RUST_INLINE_HELPERS) -Wno-override-module -c $(patsubst %.o,%.m.bc,$@) -o $@ \ $(cmd_ld_single)) \ $(if $(rustc_objcopy),;$(OBJCOPY) $(rustc_objcopy) $@) \ diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 0ac326e43fea..4349108e75e1 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -347,7 +347,7 @@ quiet_cmd_rustc_o_rs = $(RUSTC_OR_CLIPPY_QUIET) $(quiet_modtag) $@ cmd_rustc_o_rs = $(rust_common_cmd) --emit=$(if $(CONFIG_RUST_INLINE_HELPERS),llvm-bc=$(patsubst %.o,%.bc,$@),obj=$@) $< \ $(if $(CONFIG_RUST_INLINE_HELPERS),;$(LLVM_LINK) --internalize --suppress-warnings $(patsubst %.o,%.bc,$@) \ $(objtree)/rust/helpers/helpers$(if $(part-of-module),_module).bc -o $(patsubst %.o,%.m.bc,$@); \ - $(CC) $(CLANG_FLAGS) $(KBUILD_CFLAGS) \ + $(CC) $(CLANG_FLAGS) $(filter-out $(CC_FLAGS_LTO),$(KBUILD_CFLAGS)) \ $(CC_FLAGS_RUST_INLINE_HELPERS) -Wno-override-module -c $(patsubst %.o,%.m.bc,$@) -o $@ \ $(cmd_ld_single)) \ $(cmd_objtool) From 7dd6343fc127935425a81a8f1989907996c2868d Mon Sep 17 00:00:00 2001 From: Younes Akhouayri Date: Sat, 22 Aug 2026 10:44:47 +0200 Subject: [PATCH 7/8] rust: num: restrict bool conversion to unsigned Bounded From turns true into 1. A signed Bounded with N = 1 can hold only -1 and 0. The current implementation can therefore create a value that breaks Bounded's invariant. Deref relies on that invariant and calls unreachable_unchecked() when it is broken, so safe Rust can reach undefined behavior. The other primitive conversions require the source and destination to have the same signedness. Treat bool as an unsigned one-bit value and allow conversions between bool and Bounded only when the backing integer type is unsigned. Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type") Closes: https://lore.kernel.org/rust-for-linux/OzuVxu0--J-9@younes.io/ Cc: stable@vger.kernel.org Suggested-by: Alexandre Courbot Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Younes Akhouayri Reviewed-by: Alexandre Courbot Link: https://patch.msgid.link/20260822-fix-rust-bounded-from-bool-submit-v4-1-aa780bfe7f30@younes.io Signed-off-by: Miguel Ojeda --- rust/kernel/num/bounded.rs | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/rust/kernel/num/bounded.rs b/rust/kernel/num/bounded.rs index d192610a687d..2a2b0a4bca5e 100644 --- a/rust/kernel/num/bounded.rs +++ b/rust/kernel/num/bounded.rs @@ -13,7 +13,10 @@ }; use kernel::{ - num::Integer, + num::{ + Integer, + Unsigned, // + }, prelude::*, // }; @@ -174,13 +177,16 @@ fn fits_within(value: T, num_bits: u32) -> bool { /// // `u8` (regardless of the passed value). /// // let _ = Bounded::::from(10u8); /// -/// // Booleans can be converted into single-bit `Bounded`s. +/// // Booleans can be converted into unsigned `Bounded`s. /// /// let v = Bounded::::from(false); /// assert_eq!(v.get(), 0); /// /// let v = Bounded::::from(true); /// assert_eq!(v.get(), 1); +/// +/// // This does not build because `i8` is signed. +/// // let _ = Bounded::::from(true); /// ``` /// /// Infallible conversions from a [`Bounded`] to a primitive integer are also supported, and @@ -203,12 +209,16 @@ fn fits_within(value: T, num_bits: u32) -> bool { /// let _v = Bounded::::new::<10>(); /// // assert_eq!(u8::from(_v), 10); /// -/// // Single-bit `Bounded`s can be converted into a boolean. +/// // Unsigned single-bit `Bounded`s can be converted into a boolean. /// let v = Bounded::::new::<1>(); /// assert_eq!(bool::from(v), true); /// /// let v = Bounded::::new::<0>(); /// assert_eq!(bool::from(v), false); +/// +/// // This does not build because `i8` is signed. +/// // let v = Bounded::::new::<-1>(); +/// // let _ = bool::from(v); /// ``` /// /// Fallible conversions from any primitive integer to any [`Bounded`] are also supported using the @@ -1109,31 +1119,33 @@ fn from(value: Bounded) -> $type { i8 i16 i32 i64 isize ); -// Single-bit `Bounded`s can be converted from/to a boolean. +// Unsigned single-bit `Bounded`s can be converted to a boolean. impl From> for bool where - T: Integer + Zeroable, + T: Integer + Zeroable, { fn from(value: Bounded) -> Self { value.get() != Zeroable::zeroed() } } +// Booleans can be converted to unsigned `Bounded`s. + impl From for Bounded where - T: Integer + From, + T: Integer + From, { fn from(value: bool) -> Self { - // SAFETY: A boolean can be represented using a single bit, and thus fits within any - // integer type for any `N` > 0. + // SAFETY: A boolean is represented by `0` or `1`, so it fits within any valid unsigned + // `Bounded` width. unsafe { Self::__new(T::from(value)) } } } impl Bounded where - T: Integer + Zeroable, + T: Integer + Zeroable, { /// Converts this [`Bounded`] into a [`bool`]. /// From 1b0bab4a873f1034c27573cfc613394cff7e0a5b Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Sun, 23 Aug 2026 21:35:29 +0200 Subject: [PATCH 8/8] rust: kbuild: disambiguate `zerocopy_derive` for `rusttest` The `rustc-dev` components for Rust 1.82.0 through 1.87.0 include a precompiled `zerocopy_derive` procedural macro in the sysroot. This range includes Rust 1.85.0, our minimum supported version. This makes `rusttest` fail because the compiler finds both the sysroot copy and the copy built in `rust/test`: error[E0464]: multiple candidates for `dylib` dependency `zerocopy_derive` found --> rust/kernel/prelude.rs:70:9 | 70 | pub use zerocopy_derive::{ | ^^^^^^^^^^^^^^^ | = note: candidate #1: .../lib/rustlib/x86_64-unknown-linux-gnu/lib/libzerocopy_derive-54d2b38896fa6bc5.so = note: candidate #2: .../rust/test/libzerocopy_derive.so Commit fe39a233ea52 ("rust: kbuild: disambiguate `zerocopy` for `rusttest`") fixed the equivalent ambiguity for `zerocopy`. Thus point to the dependency explicitly in this case too. Cc: Antoni Boucher Cc: stable@vger.kernel.org Fixes: 506054980429 ("rust: zerocopy-derive: enable support in kbuild") Link: https://patch.msgid.link/20260823193529.156066-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda --- rust/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rust/Makefile b/rust/Makefile index 3afaad4a4a3a..9211d82ac96d 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -350,7 +350,8 @@ rusttestlib-pin_init: $(src)/pin-init/src/lib.rs rusttestlib-macros \ rusttestlib-kernel: private rustc_target_flags = --extern ffi \ --extern build_error --extern macros --extern pin_init \ --extern bindings --extern uapi \ - --extern zerocopy=$(objtree)/$(obj)/test/libzerocopy.rlib --extern zerocopy_derive + --extern zerocopy=$(objtree)/$(obj)/test/libzerocopy.rlib \ + --extern zerocopy_derive=$(objtree)/$(obj)/test/$(libzerocopy_derive_name) rusttestlib-kernel: $(src)/kernel/lib.rs rusttestlib-bindings rusttestlib-uapi \ rusttestlib-build_error rusttestlib-pin_init $(obj)/$(libmacros_name) \ $(obj)/bindings.o rusttestlib-zerocopy rusttestlib-zerocopy_derive FORCE