From 3ac88a9948792b092a4b11323e2abd1ecbe0cc68 Mon Sep 17 00:00:00 2001 From: Alexandre Courbot Date: Tue, 24 Feb 2026 11:25:34 +0900 Subject: [PATCH 1/8] rust: str: make NullTerminatedFormatter public If `CONFIG_BLOCK` is disabled, the following warnings are displayed during build: warning: struct `NullTerminatedFormatter` is never constructed --> ../rust/kernel/str.rs:667:19 | 667 | pub(crate) struct NullTerminatedFormatter<'a> { | ^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default warning: associated function `new` is never used --> ../rust/kernel/str.rs:673:19 | 671 | impl<'a> NullTerminatedFormatter<'a> { | ------------------------------------ associated function in this implementation 672 | /// Create a new [`Self`] instance. 673 | pub(crate) fn new(buffer: &'a mut [u8]) -> Option> { Fix them by making `NullTerminatedFormatter` public, as it could be useful for drivers anyway. Fixes: cdde7a1951ff ("rust: str: introduce `NullTerminatedFormatter`") Signed-off-by: Alexandre Courbot Reviewed-by: Alice Ryhl Reviewed-by: Andreas Hindborg Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260224-nullterminatedformatter-v1-1-5bef7b9b3d4c@nvidia.com Signed-off-by: Miguel Ojeda --- rust/kernel/str.rs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs index fa87779d2253..3f8918764640 100644 --- a/rust/kernel/str.rs +++ b/rust/kernel/str.rs @@ -664,13 +664,13 @@ impl fmt::Write for Formatter<'_> { /// /// * The first byte of `buffer` is always zero. /// * The length of `buffer` is at least 1. -pub(crate) struct NullTerminatedFormatter<'a> { +pub struct NullTerminatedFormatter<'a> { buffer: &'a mut [u8], } impl<'a> NullTerminatedFormatter<'a> { /// Create a new [`Self`] instance. - pub(crate) fn new(buffer: &'a mut [u8]) -> Option> { + pub fn new(buffer: &'a mut [u8]) -> Option> { *(buffer.first_mut()?) = 0; // INVARIANT: From e174dd14bf0beac811a5201e370ab26ce8c67f23 Mon Sep 17 00:00:00 2001 From: Gary Guo Date: Tue, 24 Feb 2026 15:29:56 +0800 Subject: [PATCH 2/8] rust: kbuild: emit dep-info into $(depfile) directly MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit After commit 295d8398c67e ("kbuild: specify output names separately for each emission type from rustc"), the preferred pattern is to ask rustc to emit dependency information into $(depfile) directly, and after commit 2185242faddd ("kbuild: remove sed commands after rustc rules"), the post-processing to remove comments is no longer necessary as fixdep can handle comments directly. Thus, emit dep-info into $(depfile) directly and remove the mv and sed invocation. This fixes the issue where a non-ignored .d file is emitted during compilation and removed shortly afterwards. [ Like Gary mentioned in Zulip, this likely happened due to rebasing the builds part of the old `syn` work I had. - Miguel ] Reported-by: Onur Özkan Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/syn.20artifact.20being.20tracked.20by.20git/with/575467879 Fixes: 7dbe46c0b11d ("rust: kbuild: add proc macro library support") Signed-off-by: Gary Guo Tested-by: Onur Özkan Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260224072957.214979-1-gary@garyguo.net [ Reworded for a couple of typos. - Miguel ] Signed-off-by: Miguel Ojeda --- rust/Makefile | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/rust/Makefile b/rust/Makefile index 629b3bdd2b20..1500993d7ecc 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -526,11 +526,9 @@ quiet_cmd_rustc_procmacrolibrary = $(RUSTC_OR_CLIPPY_QUIET) PL $@ cmd_rustc_procmacrolibrary = \ $(if $(skip_clippy),$(RUSTC),$(RUSTC_OR_CLIPPY)) \ $(filter-out $(skip_flags),$(rust_common_flags) $(rustc_target_flags)) \ - --emit=dep-info,link --crate-type rlib -O \ + --emit=dep-info=$(depfile) --emit=link=$@ --crate-type rlib -O \ --out-dir $(objtree)/$(obj) -L$(objtree)/$(obj) \ - --crate-name $(patsubst lib%.rlib,%,$(notdir $@)) $<; \ - mv $(objtree)/$(obj)/$(patsubst lib%.rlib,%,$(notdir $@)).d $(depfile); \ - sed -i '/^\#/d' $(depfile) + --crate-name $(patsubst lib%.rlib,%,$(notdir $@)) $< $(obj)/libproc_macro2.rlib: private skip_clippy = 1 $(obj)/libproc_macro2.rlib: private rustc_target_flags = $(proc_macro2-flags) From dda135077ecc9f15c407f094dcfe7800376be867 Mon Sep 17 00:00:00 2001 From: Gary Guo Date: Thu, 26 Feb 2026 15:21:11 +0000 Subject: [PATCH 3/8] rust: build: remap path to avoid absolute path When building with an out directory (O=), absolute paths can end up in the file name in `#[track_caller]` or the panic message. This is not desirable as this leaks the exact path being used to build the kernel and means that the same location can appear in two forms (relative or absolute). This is reported by Asahi [1] and is being workaround in [2] previously to force everything to be absolute path. Using absolute path for everything solves the inconsistency, however it does not address the reproducibility issue. So, fix this by remap all absolute paths to srctree to relative path instead. This is previously attempted in commit dbdffaf50ff9 ("kbuild, rust: use -fremap-path-prefix to make paths relative") but that was reverted as remapping debug info causes some tool (e.g. objdump) to be unable to find sources. Therefore, use `--remap-path-scope` to only remap macros but leave debuginfo untouched. `--remap-path-scope` is only stable in Rust 1.95, so use `rustc-option` to detect its presence. This feature has been available as `-Zremap-path-scope` for all versions that we support; however due to bugs in the Rust compiler, it does not work reliably until 1.94. I opted to not enable it for 1.94 as it's just a single version that we missed. This change can be validated by building a kernel with O=, strip debug info on vmlinux, and then check if the absolute path exists in `strings vmlinux`, e.g. `strings vmlinux |grep \/home`. Reported-by: Janne Grunau Reported-by: Asahi Lina Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Per-call-site.20data.20and.20lock.20class.20keys/near/572466559 [1] Link: https://github.com/AsahiLinux/linux/commit/54ab88878869036c9d6620101bfe17a81e88c2f9 [2] Signed-off-by: Gary Guo Acked-by: Nicolas Schier # kbuild Link: https://patch.msgid.link/20260226152112.3222886-1-gary@kernel.org [ Reworded for few typos. - Miguel ] Signed-off-by: Miguel Ojeda --- Makefile | 3 +++ rust/Makefile | 5 +++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 2446085983f7..73a39592f112 100644 --- a/Makefile +++ b/Makefile @@ -1113,6 +1113,9 @@ KBUILD_CFLAGS += -fno-builtin-wcslen # change __FILE__ to the relative path to the source directory ifdef building_out_of_srctree KBUILD_CPPFLAGS += -fmacro-prefix-map=$(srcroot)/= +ifeq ($(call rustc-option-yn, --remap-path-scope=macro),y) +KBUILD_RUSTFLAGS += --remap-path-prefix=$(srcroot)/= --remap-path-scope=macro +endif endif # include additional Makefiles when needed diff --git a/rust/Makefile b/rust/Makefile index 1500993d7ecc..9801af2e1e02 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -148,7 +148,8 @@ doctests_modifiers_workaround := $(rustdoc_modifiers_workaround)$(if $(call rust 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) --remap-path-prefix=% --remap-path-scope=%, \ + $(if $(rustdoc_host),$(rust_common_flags),$(rust_flags))) \ $(rustc_target_flags) -L$(objtree)/$(obj) \ -Zunstable-options --generate-link-to-definition \ --output $(rustdoc_output) \ @@ -334,7 +335,7 @@ quiet_cmd_rustdoc_test_kernel = RUSTDOC TK $< rm -rf $(objtree)/$(obj)/test/doctests/kernel; \ mkdir -p $(objtree)/$(obj)/test/doctests/kernel; \ OBJTREE=$(abspath $(objtree)) \ - $(RUSTDOC) --test $(filter-out --remap-path-prefix=%,$(rust_flags)) \ + $(RUSTDOC) --test $(filter-out --remap-path-prefix=% --remap-path-scope=%,$(rust_flags)) \ -L$(objtree)/$(obj) --extern ffi --extern pin_init \ --extern kernel --extern build_error --extern macros \ --extern bindings --extern uapi \ From a075082a15e7f5c4889d0cbb51a4041c332cb00c Mon Sep 17 00:00:00 2001 From: Benno Lossin Date: Mon, 2 Mar 2026 15:04:14 +0100 Subject: [PATCH 4/8] rust: pin-init: internal: init: remove `#[disable_initialized_field_access]` Gary noticed [1] that the initializer macros as well as the `[Pin]Init` traits cannot support unaligned fields, since they use operations that require aligned pointers. This means that any code using structs with unaligned fields in pin-init is unsound. By default, the `init!` macro generates references to initialized fields, which makes the compiler check that those fields are aligned. However, we added the `#[disable_initialized_field_access]` attribute to avoid this behavior in commit ceca298c53f9 ("rust: pin-init: internal: init: add escape hatch for referencing initialized fields"). Thus remove the `#[disable_initialized_field_access]` attribute from `init!`, which is the only safe way to create an initializer handling unaligned fields. If support for in-place initializing structs with unaligned fields is required in the future, we could figure out a solution. This is tracked in [2]. Reported-by: Gary Guo Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/initialized.20field.20accessor.20detection/with/576210658 [1] Link: https://github.com/Rust-for-Linux/pin-init/issues/112 [2] Fixes: ceca298c53f9 ("rust: pin-init: internal: init: add escape hatch for referencing initialized fields") Signed-off-by: Benno Lossin Acked-by: Janne Grunau Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260302140424.4097655-1-lossin@kernel.org [ Adjusted tags and reworded as discussed. - Miguel ] Signed-off-by: Miguel Ojeda --- rust/pin-init/internal/src/init.rs | 39 ++++++------------------------ 1 file changed, 8 insertions(+), 31 deletions(-) diff --git a/rust/pin-init/internal/src/init.rs b/rust/pin-init/internal/src/init.rs index 42936f915a07..da53adc44ecf 100644 --- a/rust/pin-init/internal/src/init.rs +++ b/rust/pin-init/internal/src/init.rs @@ -62,7 +62,6 @@ impl InitializerKind { enum InitializerAttribute { DefaultError(DefaultErrorAttribute), - DisableInitializedFieldAccess, } struct DefaultErrorAttribute { @@ -86,6 +85,7 @@ pub(crate) fn expand( let error = error.map_or_else( || { if let Some(default_error) = attrs.iter().fold(None, |acc, attr| { + #[expect(irrefutable_let_patterns)] if let InitializerAttribute::DefaultError(DefaultErrorAttribute { ty }) = attr { Some(ty.clone()) } else { @@ -145,15 +145,7 @@ pub(crate) fn expand( }; // `mixed_site` ensures that the data is not accessible to the user-controlled code. let data = Ident::new("__data", Span::mixed_site()); - let init_fields = init_fields( - &fields, - pinned, - !attrs - .iter() - .any(|attr| matches!(attr, InitializerAttribute::DisableInitializedFieldAccess)), - &data, - &slot, - ); + let init_fields = init_fields(&fields, pinned, &data, &slot); let field_check = make_field_check(&fields, init_kind, &path); Ok(quote! {{ // We do not want to allow arbitrary returns, so we declare this type as the `Ok` return @@ -236,7 +228,6 @@ fn get_init_kind(rest: Option<(Token![..], Expr)>, dcx: &mut DiagCtxt) -> InitKi fn init_fields( fields: &Punctuated, pinned: bool, - generate_initialized_accessors: bool, data: &Ident, slot: &Ident, ) -> TokenStream { @@ -272,13 +263,6 @@ fn init_fields( unsafe { &mut (*#slot).#ident } } }; - let accessor = generate_initialized_accessors.then(|| { - quote! { - #(#cfgs)* - #[allow(unused_variables)] - let #ident = #accessor; - } - }); quote! { #(#attrs)* { @@ -286,7 +270,9 @@ fn init_fields( // SAFETY: TODO unsafe { #write(::core::ptr::addr_of_mut!((*#slot).#ident), #value_ident) }; } - #accessor + #(#cfgs)* + #[allow(unused_variables)] + let #ident = #accessor; } } InitializerKind::Init { ident, value, .. } => { @@ -326,20 +312,15 @@ fn init_fields( }, ) }; - let accessor = generate_initialized_accessors.then(|| { - quote! { - #(#cfgs)* - #[allow(unused_variables)] - let #ident = #accessor; - } - }); quote! { #(#attrs)* { let #init = #value; #value_init } - #accessor + #(#cfgs)* + #[allow(unused_variables)] + let #ident = #accessor; } } InitializerKind::Code { block: value, .. } => quote! { @@ -466,10 +447,6 @@ impl Parse for Initializer { if a.path().is_ident("default_error") { a.parse_args::() .map(InitializerAttribute::DefaultError) - } else if a.path().is_ident("disable_initialized_field_access") { - a.meta - .require_path_only() - .map(|_| InitializerAttribute::DisableInitializedFieldAccess) } else { Err(syn::Error::new_spanned(a, "unknown initializer attribute")) } From 580cc37b1de4fcd9997c48d7080e744533f09f36 Mon Sep 17 00:00:00 2001 From: Benno Lossin Date: Mon, 2 Mar 2026 15:04:15 +0100 Subject: [PATCH 5/8] rust: pin-init: internal: init: document load-bearing fact of field accessors The functions `[Pin]Init::__[pinned_]init` and `ptr::write` called from the `init!` macro require the passed pointer to be aligned. This fact is ensured by the creation of field accessors to previously initialized fields. Since we missed this very important fact from the beginning [1], document it in the code. Link: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/initialized.20field.20accessor.20detection/with/576210658 [1] Fixes: 90e53c5e70a6 ("rust: add pin-init API core") Cc: # 6.6.y, 6.12.y: 42415d163e5d: rust: pin-init: add references to previously initialized fields Cc: # 6.6.y, 6.12.y, 6.18.y, 6.19.y Signed-off-by: Benno Lossin Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260302140424.4097655-2-lossin@kernel.org [ Updated Cc: stable@ tags as discussed. - Miguel ] Signed-off-by: Miguel Ojeda --- rust/pin-init/internal/src/init.rs | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/rust/pin-init/internal/src/init.rs b/rust/pin-init/internal/src/init.rs index da53adc44ecf..738f62c8105c 100644 --- a/rust/pin-init/internal/src/init.rs +++ b/rust/pin-init/internal/src/init.rs @@ -251,6 +251,10 @@ fn init_fields( }); // Again span for better diagnostics let write = quote_spanned!(ident.span()=> ::core::ptr::write); + // NOTE: the field accessor ensures that the initialized field is properly aligned. + // Unaligned fields will cause the compiler to emit E0793. We do not support + // unaligned fields since `Init::__init` requires an aligned pointer; the call to + // `ptr::write` below has the same requirement. let accessor = if pinned { let project_ident = format_ident!("__project_{ident}"); quote! { @@ -278,6 +282,10 @@ fn init_fields( InitializerKind::Init { ident, value, .. } => { // Again span for better diagnostics let init = format_ident!("init", span = value.span()); + // NOTE: the field accessor ensures that the initialized field is properly aligned. + // Unaligned fields will cause the compiler to emit E0793. We do not support + // unaligned fields since `Init::__init` requires an aligned pointer; the call to + // `ptr::write` below has the same requirement. let (value_init, accessor) = if pinned { let project_ident = format_ident!("__project_{ident}"); ( From fdbaa9d2b78e0da9e1aeb303bbdc3adfe6d8e749 Mon Sep 17 00:00:00 2001 From: Benno Lossin Date: Wed, 11 Mar 2026 11:50:49 +0100 Subject: [PATCH 6/8] rust: pin-init: replace shadowed return token by `unsafe`-to-create token We use a unit struct `__InitOk` in the closure generated by the initializer macros as the return value. We shadow it by creating a struct with the same name again inside of the closure, preventing early returns of `Ok` in the initializer (before all fields have been initialized). In the face of Type Alias Impl Trait (TAIT) and the next trait solver, this solution no longer works [1]. The shadowed struct can be named through type inference. In addition, there is an RFC proposing to add the feature of path inference to Rust, which would similarly allow [2]. Thus remove the shadowed token and replace it with an `unsafe` to create token. The reason we initially used the shadowing solution was because an alternative solution used a builder pattern. Gary writes [3]: In the early builder-pattern based InitOk, having a single InitOk type for token is unsound because one can launder an InitOk token used for one place to another initializer. I used a branded lifetime solution, and then you figured out that using a shadowed type would work better because nobody could construct it at all. The laundering issue does not apply to the approach we ended up with today. With this change, the example by Tim Chirananthavat in [1] no longer compiles and results in this error: error: cannot construct `pin_init::__internal::InitOk` with struct literal syntax due to private fields --> src/main.rs:26:17 | 26 | InferredType {} | ^^^^^^^^^^^^ | = note: private field `0` that was not provided help: you might have meant to use the `new` associated function | 26 - InferredType {} 26 + InferredType::new() | Applying the suggestion of using the `::new()` function, results in another expected error: error[E0133]: call to unsafe function `pin_init::__internal::InitOk::new` is unsafe and requires unsafe block --> src/main.rs:26:17 | 26 | InferredType::new() | ^^^^^^^^^^^^^^^^^^^ call to unsafe function | = note: consult the function's documentation for information on how to avoid undefined behavior Reported-by: Tim Chirananthavat Link: https://github.com/rust-lang/rust/issues/153535 [1] Link: https://github.com/rust-lang/rfcs/pull/3444#issuecomment-4016145373 [2] Link: https://github.com/rust-lang/rust/issues/153535#issuecomment-4017620804 [3] Fixes: fc6c6baa1f40 ("rust: init: add initialization macros") Cc: stable@vger.kernel.org Signed-off-by: Benno Lossin Reviewed-by: Alice Ryhl Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260311105056.1425041-1-lossin@kernel.org [ Added period as mentioned. - Miguel ] Signed-off-by: Miguel Ojeda --- rust/pin-init/internal/src/init.rs | 22 +++++++--------------- rust/pin-init/src/__internal.rs | 28 ++++++++++++++++++++++++---- 2 files changed, 31 insertions(+), 19 deletions(-) diff --git a/rust/pin-init/internal/src/init.rs b/rust/pin-init/internal/src/init.rs index 738f62c8105c..2fe918f4d82a 100644 --- a/rust/pin-init/internal/src/init.rs +++ b/rust/pin-init/internal/src/init.rs @@ -148,11 +148,6 @@ pub(crate) fn expand( let init_fields = init_fields(&fields, pinned, &data, &slot); let field_check = make_field_check(&fields, init_kind, &path); Ok(quote! {{ - // We do not want to allow arbitrary returns, so we declare this type as the `Ok` return - // type and shadow it later when we insert the arbitrary user code. That way there will be - // no possibility of returning without `unsafe`. - struct __InitOk; - // Get the data about fields from the supplied type. // SAFETY: TODO let #data = unsafe { @@ -162,18 +157,15 @@ pub(crate) fn expand( #path::#get_data() }; // Ensure that `#data` really is of type `#data` and help with type inference: - let init = ::pin_init::__internal::#data_trait::make_closure::<_, __InitOk, #error>( + let init = ::pin_init::__internal::#data_trait::make_closure::<_, #error>( #data, move |slot| { - { - // Shadow the structure so it cannot be used to return early. - struct __InitOk; - #zeroable_check - #this - #init_fields - #field_check - } - Ok(__InitOk) + #zeroable_check + #this + #init_fields + #field_check + // SAFETY: we are the `init!` macro that is allowed to call this. + Ok(unsafe { ::pin_init::__internal::InitOk::new() }) } ); let init = move |slot| -> ::core::result::Result<(), #error> { diff --git a/rust/pin-init/src/__internal.rs b/rust/pin-init/src/__internal.rs index 90f18e9a2912..90adbdc1893b 100644 --- a/rust/pin-init/src/__internal.rs +++ b/rust/pin-init/src/__internal.rs @@ -46,6 +46,24 @@ where } } +/// Token type to signify successful initialization. +/// +/// Can only be constructed via the unsafe [`Self::new`] function. The initializer macros use this +/// token type to prevent returning `Ok` from an initializer without initializing all fields. +pub struct InitOk(()); + +impl InitOk { + /// Creates a new token. + /// + /// # Safety + /// + /// This function may only be called from the `init!` macro in `../internal/src/init.rs`. + #[inline(always)] + pub unsafe fn new() -> Self { + Self(()) + } +} + /// This trait is only implemented via the `#[pin_data]` proc-macro. It is used to facilitate /// the pin projections within the initializers. /// @@ -68,9 +86,10 @@ pub unsafe trait PinData: Copy { type Datee: ?Sized + HasPinData; /// Type inference helper function. - fn make_closure(self, f: F) -> F + #[inline(always)] + fn make_closure(self, f: F) -> F where - F: FnOnce(*mut Self::Datee) -> Result, + F: FnOnce(*mut Self::Datee) -> Result, { f } @@ -98,9 +117,10 @@ pub unsafe trait InitData: Copy { type Datee: ?Sized + HasInitData; /// Type inference helper function. - fn make_closure(self, f: F) -> F + #[inline(always)] + fn make_closure(self, f: F) -> F where - F: FnOnce(*mut Self::Datee) -> Result, + F: FnOnce(*mut Self::Datee) -> Result, { f } From 487f9b3dc6e507a982f1b984aa6bfbd9dc4b0567 Mon Sep 17 00:00:00 2001 From: John Hubbard Date: Wed, 11 Mar 2026 21:19:34 -0700 Subject: [PATCH 7/8] rust: cpufreq: suppress clippy::double_parens in Policy doctest The kernel fmt! proc macro wraps each format argument as &(arg). Passing a tuple such as (a, b) produces &((a, b)) after expansion. Clippy flags that as double_parens, but it is a false positive fixed in Clippy 1.92 [1] [2]. Suppress the warning on the affected doctest function with a reason attribute so it can be removed once the minimum toolchain moves past 1.92. [ We may end up deciding to support per-version Clippy lints, in which case we will need [3]. In the future, if [4] gets fixed, we may be able to use `Delimiter::None` as Gary suggested in [5]. Link: https://lore.kernel.org/rust-for-linux/20260307170929.153892-1-ojeda@kernel.org/ [3] Link: https://github.com/rust-lang/rust/issues/67062 [4] Link: https://lore.kernel.org/rust-for-linux/DGUA5GY2DGYN.3PG0FKLG7GFN1@garyguo.net/ [5] - Miguel ] Link: https://github.com/rust-lang/rust-clippy/issues/15852 [1] Link: https://github.com/rust-lang/rust-clippy/pull/15939 [2] Suggested-by: Gary Guo Signed-off-by: John Hubbard Acked-by: Viresh Kumar Link: https://patch.msgid.link/20260312041934.362840-2-jhubbard@nvidia.com [ Reworded to replace GitHub-like short link with full URLs in Link tags. Reworded reason string to match the style of a couple others we have elsewhere. - Miguel ] Signed-off-by: Miguel Ojeda --- rust/kernel/cpufreq.rs | 1 + 1 file changed, 1 insertion(+) diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs index 76faa1ac8501..f5adee48d40c 100644 --- a/rust/kernel/cpufreq.rs +++ b/rust/kernel/cpufreq.rs @@ -401,6 +401,7 @@ impl TableBuilder { /// ``` /// use kernel::cpufreq::{DEFAULT_TRANSITION_LATENCY_NS, Policy}; /// +/// #[allow(clippy::double_parens, reason = "False positive before 1.92.0")] /// fn update_policy(policy: &mut Policy) { /// policy /// .set_dvfs_possible_from_any_cpu(true) From 592c61f3bfceaa29f8275696bd67c3dfad7ef72e Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Thu, 12 Mar 2026 12:10:14 +0100 Subject: [PATCH 8/8] rust: kbuild: allow `unused_features` Starting with the upcoming Rust 1.96.0 (to be released 2026-05-28), `rustc` introduces the new lint `unused_features` [1], which warns [2]: warning: feature `used_with_arg` is declared but not used --> :1:93 | 1 | #![feature(asm_const,asm_goto,arbitrary_self_types,lint_reasons,offset_of_nested,raw_ref_op,used_with_arg)] | ^^^^^^^^^^^^^ | = note: `#[warn(unused_features)]` (part of `#[warn(unused)]`) on by default The original goal of using `-Zcrate-attr` automatically was that there is a consistent set of features enabled and managed globally for all Rust kernel code (modulo exceptions like the `rust/` crated). While we could require crates to enable features manually (even if we still keep the `-Zallow-features=` list, i.e. removing the `-Zcrate-attr` list), it is not really worth making all developers worry about it just for a new lint. The features are expected to eventually become stable anyway (most already did), and thus having to remove features in every file that may use them is not worth it either. Thus just allow the new lint globally. The lint actually existed for a long time, which is why `rustc` does not complain about an unknown lint in the stable versions we support, but it was "disabled" years ago [3], and now it was made to work again. For extra context, the new implementation of the lint has already been improved to avoid linting about features that became stable thanks to Benno's report and the ensuing discussion [4] [5], but while that helps, it is still the case that we may have features enabled that are not used for one reason or another in a particular crate. 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/152164 [1] Link: https://github.com/Rust-for-Linux/pin-init/pull/114 [2] Link: https://github.com/rust-lang/rust/issues/44232 [3] Link: https://github.com/rust-lang/rust/issues/153523 [4] Link: https://github.com/rust-lang/rust/pull/153610 [5] Reviewed-by: Benno Lossin Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260312111014.74198-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 73a39592f112..587345f16c97 100644 --- a/Makefile +++ b/Makefile @@ -476,6 +476,7 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS) export rust_common_flags := --edition=2021 \ -Zbinary_dep_depinfo=y \ -Astable_features \ + -Aunused_features \ -Dnon_ascii_idents \ -Dunsafe_op_in_unsafe_fn \ -Wmissing_docs \