kernel/linux.git/rust/Makefile, branch v6.12.80

rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0

2026-03-04T12:21:54+00:00

[ Upstream commit 0a9be83e57de0d0ca8ca4ec610bc344f17a8e5e7 ] Custom target specifications are unstable, but starting with Rust 1.95.0, `rustc` requires to explicitly pass `-Zunstable-options` to use them [1]: error: error loading target specification: custom targets are unstable and require `-Zunstable-options` | = help: run `rustc --print target-list` for a list of built-in targets David (Rust compiler team lead), writes: "We're destabilising custom targets to allow us to move forward with build-std without accidentally exposing functionality that we'd like to revisit prior to committing to. I'll start a thread on Zulip to discuss with the RfL team how we can come up with an alternative for them." Thus pass it. Cc: David Wood Cc: Wesley Wiser Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/151534 [1] Reviewed-by: Gary Guo Tested-by: Gary Guo Link: https://patch.msgid.link/20260206204535.39431-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

rust: kbuild: workaround `rustdoc` doctests modifier bug

2025-11-24T09:36:07+00:00

[ Upstream commit fad472efab0a805dd939f017c5b8669a786a4bcf ] The `rustdoc` modifiers bug [1] was fixed in Rust 1.90.0 [2], for which we added a workaround in commit abbf9a449441 ("rust: workaround `rustdoc` target modifiers bug"). However, `rustdoc`'s doctest generation still has a similar issue [3], being fixed at [4], which does not affect us because we apply the workaround to both, and now, starting with Rust 1.91.0 (released 2025-10-30), `-Zsanitizer` is a target modifier too [5], which means we fail with: RUSTDOC TK rust/kernel/lib.rs error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `kernel` --> rust/kernel/lib.rs:3:1 | 3 | //! The `kernel` crate. | ^ | = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core` = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core` = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error A simple way around is to add the sanitizer to the list in the existing workaround (especially if we had not started to pass the sanitizer flags in the previous commit, since in that case that would not be necessary). However, that still applies the workaround in more cases than necessary. Instead, only modify the doctests flags to ignore the check for sanitizers, so that it is more local (and thus the compiler keeps checking it for us in the normal `rustdoc` calls). Since the previous commit already treated the `rustdoc` calls as kernel objects, this should allow us in the future to easily remove this workaround when the time comes. By the way, the `-Cunsafe-allow-abi-mismatch` flag overwrites previous ones rather than appending, so it needs to be all done in the same flag. Moreover, unknown modifiers are rejected, and thus we have to gate based on the version too. Finally, `-Zsanitizer-cfi-normalize-integers` is not affected (in Rust 1.91.0), so it is not needed in the workaround for the moment. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/issues/144521 [1] Link: https://github.com/rust-lang/rust/pull/144523 [2] Link: https://github.com/rust-lang/rust/issues/146465 [3] Link: https://github.com/rust-lang/rust/pull/148068 [4] Link: https://github.com/rust-lang/rust/pull/138736 [5] Reviewed-by: Alice Ryhl Tested-by: Justin M. Forbes Link: https://patch.msgid.link/20251102212853.1505384-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda [ added --remap-path-prefix comments missing in stable branch ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

rust: kbuild: treat `build_error` and `rustdoc` as kernel objects

2025-11-24T09:36:07+00:00

[ Upstream commit 16c43a56b79e2c3220b043236369a129d508c65a ] Even if normally `build_error` isn't a kernel object, it should still be treated as such so that we pass the same flags. Similarly, `rustdoc` targets are never kernel objects, but we need to treat them as such. Otherwise, starting with Rust 1.91.0 (released 2025-10-30), `rustc` will complain about missing sanitizer flags since `-Zsanitizer` is a target modifier too [1]: error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `build_error` --> rust/build_error.rs:3:1 | 3 | //! Build-time error. | ^ | = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core` = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core` = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error Thus explicitly mark them as kernel objects. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138736 [1] Reviewed-by: Alice Ryhl Tested-by: Justin M. Forbes Link: https://patch.msgid.link/20251102212853.1505384-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

rust: Add -fno-isolate-erroneous-paths-dereference to bindgen_skip_c_flags

2025-11-24T09:35:49+00:00

[ Upstream commit fe4b3a34e9a9654d98d274218dac0270779db0ae ] It's used to work around an objtool issue since commit abb2a5572264 ("LoongArch: Add cflag -fno-isolate-erroneous-paths-dereference"), but it's then passed to bindgen and cause an error because Clang does not have this option. Fixes: abb2a5572264 ("LoongArch: Add cflag -fno-isolate-erroneous-paths-dereference") Acked-by: Miguel Ojeda Tested-by: Mingcong Bai Signed-off-by: Xi Ruoyao Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin

rust: workaround `rustdoc` target modifiers bug

2025-08-20T16:30:57+00:00

commit abbf9a44944171ca99c150adad9361a2f517d3b6 upstream. Starting with Rust 1.88.0 (released 2025-06-26), `rustdoc` complains about a target modifier mismatch in configurations where `-Zfixed-x18` is passed: error: mixing `-Zfixed-x18` will cause an ABI mismatch in crate `rust_out` | = help: the `-Zfixed-x18` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset `-Zfixed-x18` in this crate is incompatible with `-Zfixed-x18=` in dependency `core` = help: set `-Zfixed-x18=` in this crate or unset `-Zfixed-x18` in `core` = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=fixed-x18` to silence this error The reason is that `rustdoc` was not passing the target modifiers when configuring the session options, and thus it would report a mismatch that did not exist as soon as a target modifier is used in a dependency. We did not notice it in the kernel until now because `-Zfixed-x18` has been a target modifier only since 1.88.0 (and it is the only one we use so far). The issue has been reported upstream [1] and a fix has been submitted [2], including a test similar to the kernel case. [ This is now fixed upstream (thanks Guillaume for the quick review), so it will be fixed in Rust 1.90.0 (expected 2025-09-18). - Miguel ] Meanwhile, conditionally pass `-Cunsafe-allow-abi-mismatch=fixed-x18` to workaround the issue on our side. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Reported-by: Konrad Dybcio Closes: https://lore.kernel.org/rust-for-linux/36cdc798-524f-4910-8b77-d7b9fac08d77@oss.qualcomm.com/ Link: https://github.com/rust-lang/rust/issues/144521 [1] Link: https://github.com/rust-lang/rust/pull/144523 [2] Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250727092317.2930617-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: kbuild: clean output before running `rustdoc`

2025-08-20T16:30:57+00:00

commit 252fea131e15aba2cd487119d1a8f546471199e2 upstream. `rustdoc` can get confused when generating documentation into a folder that contains generated files from other `rustdoc` versions. For instance, running something like: rustup default 1.78.0 make LLVM=1 rustdoc rustup default 1.88.0 make LLVM=1 rustdoc may generate errors like: error: couldn't generate documentation: invalid template: last line expected to start with a comment | = note: failed to create or modify "./Documentation/output/rust/rustdoc/src-files.js" Thus just always clean the output folder before generating the documentation -- we are anyway regenerating it every time the `rustdoc` target gets called, at least for the time being. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Reported-by: Daniel Almeida Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089/topic/x/near/527201113 Reviewed-by: Tamir Duberstein Link: https://lore.kernel.org/r/20250726133435.2460085-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: use `#[used(compiler)]` to fix build and `modpost` with Rust >= 1.89.0

2025-07-24T06:56:37+00:00

commit 7498159226772d66f150dd406be462d75964a366 upstream. Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the `rusttest` target due to undefined references such as: kernel...-cgu.0:(.text....+0x116): undefined reference to `rust_helper_kunit_get_current_test' Moreover, tooling like `modpost` gets confused: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o The reason behind both issues is that the Rust compiler will now [1] treat `#[used]` as `#[used(linker)]` instead of `#[used(compiler)]` for our targets. This means that the retain section flag (`R`, `SHF_GNU_RETAIN`) will be used and that they will be marked as `unique` too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in `rusttest` and that multiple `.modinfo` sections are generated, which confuse tooling like `modpost` because they only expect one. Thus start using `#[used(compiler)]` to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (`used_with_arg`) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3]. The changes should also be fine for previous Rust versions, since they behave the same way as before [4]. Alternatively, we could use `#[no_mangle]` or `#[export_name = ...]` since those still behave like `#[used(compiler)]`, but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts. Cc: David Wood Cc: Wesley Wiser Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/140872 [1] Link: https://github.com/rust-lang/rust/issues/93798 [2] Link: https://github.com/rust-lang/rust/pull/91504 [3] Link: https://godbolt.org/z/sxzWTMfzW [4] Reviewed-by: Alice Ryhl Acked-by: Björn Roy Baron Link: https://lore.kernel.org/r/20250712160103.1244945-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: arm: fix unknown (to Clang) argument '-mno-fdpic'

2025-07-06T09:01:33+00:00

[ Upstream commit 977c4308ee4270cf46e2c66b37de8e04670daa0c ] Currently rust on arm fails to compile due to '-mno-fdpic'. This flag disables a GCC feature that we don't want for kernel builds, so let's skip it as it doesn't apply to Clang. UPD include/generated/asm-offsets.h CALL scripts/checksyscalls.sh RUSTC L rust/core.o BINDGEN rust/bindings/bindings_generated.rs BINDGEN rust/bindings/bindings_helpers_generated.rs CC rust/helpers/helpers.o Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic' make[2]: *** [rust/Makefile:369: rust/bindings/bindings_helpers_generated.rs] Error 1 make[2]: *** Deleting file 'rust/bindings/bindings_helpers_generated.rs' make[2]: *** Waiting for unfinished jobs.... Unable to generate bindings: clang diagnosed error: error: unknown argument: '-mno-fdpic' make[2]: *** [rust/Makefile:349: rust/bindings/bindings_generated.rs] Error 1 make[2]: *** Deleting file 'rust/bindings/bindings_generated.rs' make[1]: *** [/home/pmos/build/src/linux-next-next-20250521/Makefile:1285: prepare] Error 2 make: *** [Makefile:248: __sub-make] Error 2 [ Naresh provided the draft diff [1]. Ben explained [2]: FDPIC is only relevant with no-MMU targets, and then only for userspace. When configured for the arm-*-uclinuxfdpiceabi target, GCC enables FDPIC by default to facilitate compiling userspace programs. FDPIC is never used for the kernel, and we pass -mno-fdpic when building the kernel to override the default and make sure FDPIC is disabled. and [3]: -mno-fdpic disables a GCC feature that we don't want for kernel builds. clang does not support this feature, so it always behaves as though -mno-fdpic is passed. Therefore, it should be fine to mix the two, at least as far as FDPIC is concerned. [1] https://lore.kernel.org/rust-for-linux/CA+G9fYt4otQK4pHv8pJBW9e28yHSGCDncKquwuJiJ_1ou0pq0w@mail.gmail.com/ [2] https://lore.kernel.org/rust-for-linux/aAKrq2InExQk7f_k@dell-precision-5540/ [3] https://lore.kernel.org/rust-for-linux/aAo_F_UP1Gd4jHlZ@dell-precision-5540/ - Miguel ] Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/all/CA+G9fYvOanQBYXKSg7C6EU30k8sTRC0JRPJXYu7wWK51w38QUQ@mail.gmail.com/ Suggested-by: Miguel Ojeda Acked-by: Naresh Kamboju Signed-off-by: Rudraksha Gupta Link: https://lore.kernel.org/r/20250522-rust-mno-fdpic-arm-fix-v2-1-a6f691d9c198@gmail.com [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

rust: compile libcore with edition 2024 for 1.87+

2025-06-27T10:11:40+00:00

commit f4daa80d6be7d3c55ca72a8e560afc4e21f886aa upstream. Rust 1.87 (released on 2025-05-15) compiles core library with edition 2024 instead of 2021 [1]. Ensure that the edition matches libcore's expectation to avoid potential breakage. [ J3m3 reported in Zulip [2] that the `rust-analyzer` target was broken after this patch -- indeed, we need to avoid `core-cfgs` since those are passed to the `rust-analyzer` target. So, instead, I tweaked the patch to create a new `core-edition` variable and explicitly mention the `--edition` flag instead of reusing `core-cfg`s. In addition, pass a new argument using this new variable to `generate_rust_analyzer.py` so that we set the right edition there. By the way, for future reference: the `filter-out` change is needed for Rust < 1.87, since otherwise we would skip the `--edition=2021` we just added, ending up with no edition flag, and thus the compiler would default to the 2015 one. [2] https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/near/520206547 - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138162 [1] Reported-by: est31 Closes: https://github.com/Rust-for-Linux/linux/issues/1163 Signed-off-by: Gary Guo Link: https://lore.kernel.org/r/20250517085600.2857460-1-gary@garyguo.net Signed-off-by: Miguel Ojeda [ Solved conflicts for 6.12.y backport. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: Fix enabling Rust and building with GCC for LoongArch

2025-04-10T12:39:36+00:00

commit 13c23cb4ed09466d73f1beae8956810b95add6ef upstream. This patch fixes a build issue on LoongArch when Rust is enabled and compiled with GCC by explicitly setting the bindgen target and skipping C flags that Clang doesn't support. Cc: stable@vger.kernel.org Acked-by: Miguel Ojeda Signed-off-by: WANG Rui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman