linux.git/rust/kernel/init/macros.rs, branch v6.12.80

rust: pin-init: internal: init: document load-bearing fact of field accessors

2026-04-02T11:09:50+00:00

commit 580cc37b1de4fcd9997c48d7080e744533f09f36 upstream.

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 
[ Moved changes to the declarative macro, because 6.19.y and earlier do not
  have `syn`. Also duplicated the comment for all field accessor creations.
  - Benno ]
Signed-off-by: Benno Lossin 
Signed-off-by: Greg Kroah-Hartman

rust: pin-init: add references to previously initialized fields

2026-04-02T11:09:50+00:00

commit 42415d163e5df6db799c7de6262d707e402c2c7e upstream.

After initializing a field in an initializer macro, create a variable
holding a reference that points at that field. The type is either
`Pin<&mut T>` or `&mut T` depending on the field's structural pinning
kind.

[ Applied fixes to devres and rust_driver_pci sample - Benno]
Reviewed-by: Danilo Krummrich 
Signed-off-by: Benno Lossin 
[ Removed the devres changes, because devres is not present in 6.12.y and
  earlier. Also adjusted paths in the macro to account for the fact that
  pin-init is part of the kernel crate in 6.12.y and earlier. - Benno ]
Signed-off-by: Benno Lossin 
Signed-off-by: Greg Kroah-Hartman

rust: init: allow `dead_code` warnings for Rust >= 1.89.0

2025-07-17T16:37:14+00:00

Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler
may warn:

    error: trait `MustNotImplDrop` is never used
       --> rust/kernel/init/macros.rs:927:15
        |
    927 |         trait MustNotImplDrop {}
        |               ^^^^^^^^^^^^^^^
        |
       ::: rust/kernel/sync/arc.rs:133:1
        |
    133 | #[pin_data]
        | ----------- in this procedural macro expansion
        |
        = note: `-D dead-code` implied by `-D warnings`
        = help: to override `-D warnings` add `#[allow(dead_code)]`
        = note: this error originates in the macro `$crate::__pin_data`
                which comes from the expansion of the attribute macro
                `pin_data` (in Nightly builds, run with
                -Z macro-backtrace for more info)

Thus `allow` it to clean it up.

This does not happen in mainline nor 6.15.y, because there the macro was
moved out of the `kernel` crate, and `dead_code` warnings are not
emitted if the macro is foreign to the crate. Thus this patch is
directly sent to stable and intended for 6.12.y only.

Similarly, it is not needed in previous LTSs, because there the Rust
version is pinned.

Acked-by: Benno Lossin 
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: init: add missing newline to pr_info! calls

2025-03-22T19:54:26+00:00

[ Upstream commit 6933c1067fe6df8ddb34dd68bdb2aa172cbd08c8 ]

Several pr_info! calls in rust/kernel/init.rs (both in code examples
and macro documentation) were missing a newline, causing logs to
run together. This commit updates these calls to include a trailing
newline, improving readability and consistency with the C side.

Fixes: 6841d45a3030 ("rust: init: add `stack_pin_init!` macro")
Fixes: 7f8977a7fe6d ("rust: init: add `{pin_}chain` functions to `{Pin}Init`")
Fixes: d0fdc3961270 ("rust: init: add `PinnedDrop` trait and macros")
Fixes: 4af84c6a85c6 ("rust: init: update expanded macro explanation")
Reported-by: Miguel Ojeda 
Link: https://github.com/Rust-for-Linux/linux/issues/1139
Signed-off-by: Alban Kurti 
Link: https://lore.kernel.org/r/20250206-printing_fix-v3-3-a85273b501ae@invicto.ai
[ Replaced Closes with Link since it fixes part of the issue. Added
  one more Fixes tag (still same set of stable kernels). - Miguel ]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust: start using the `#[expect(...)]` attribute

2025-03-13T12:01:42+00:00

commit 1f9ed172545687e5c04c77490a45896be6d2e459 upstream.

In Rust, it is possible to `allow` particular warnings (diagnostics,
lints) locally, making the compiler ignore instances of a given warning
within a given function, module, block, etc.

It is similar to `#pragma GCC diagnostic push` + `ignored` + `pop` in C:

    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Wunused-function"
    static void f(void) {}
    #pragma GCC diagnostic pop

But way less verbose:

    #[allow(dead_code)]
    fn f() {}

By that virtue, it makes it possible to comfortably enable more
diagnostics by default (i.e. outside `W=` levels) that may have some
false positives but that are otherwise quite useful to keep enabled to
catch potential mistakes.

The `#[expect(...)]` attribute [1] takes this further, and makes the
compiler warn if the diagnostic was _not_ produced. For instance, the
following will ensure that, when `f()` is called somewhere, we will have
to remove the attribute:

    #[expect(dead_code)]
    fn f() {}

If we do not, we get a warning from the compiler:

    warning: this lint expectation is unfulfilled
     --> x.rs:3:10
      |
    3 | #[expect(dead_code)]
      |          ^^^^^^^^^
      |
      = note: `#[warn(unfulfilled_lint_expectations)]` on by default

This means that `expect`s do not get forgotten when they are not needed.

See the next commit for more details, nuances on its usage and
documentation on the feature.

The attribute requires the `lint_reasons` [2] unstable feature, but it
is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has
already been useful to clean things up in this patch series, finding
cases where the `allow`s should not have been there.

Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s
where possible.

This feature was also an example of the ongoing collaboration between
Rust and the kernel -- we tested it in the kernel early on and found an
issue that was quickly resolved [3].

Cc: Fridtjof Stoldt 
Cc: Urgau 
Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1]
Link: https://github.com/rust-lang/rust/issues/54503 [2]
Link: https://github.com/rust-lang/rust/issues/114557 [3]
Reviewed-by: Alice Ryhl 
Reviewed-by: Trevor Gross 
Tested-by: Gary Guo 
Reviewed-by: Gary Guo 
Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: enable Clippy's `check-private-items`

2025-03-13T12:01:42+00:00

commit 624063b9ac97f40cadca32a896aafeb28b1220fd upstream.

In Rust 1.76.0, Clippy added the `check-private-items` lint configuration
option. When turned on (the default is off), it makes several lints
check private items as well.

In our case, it affects two lints we have enabled [1]:
`missing_safety_doc` and `unnecessary_safety_doc`.

It also seems to affect the new `too_long_first_doc_paragraph` lint [2],
even though the documentation does not mention it.

Thus allow the few instances remaining we currently hit and enable
the lint.

Link: https://doc.rust-lang.org/nightly/clippy/lint_configuration.html#check-private-items [1]
Link: https://rust-lang.github.io/rust-clippy/master/index.html#/too_long_first_doc_paragraph [2]
Reviewed-by: Trevor Gross 
Reviewed-by: Alice Ryhl 
Tested-by: Gary Guo 
Reviewed-by: Gary Guo 
Link: https://lore.kernel.org/r/20240904204347.168520-16-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: enable `clippy::undocumented_unsafe_blocks` lint

2025-03-13T12:01:41+00:00

commit db4f72c904cb116e2bf56afdd67fc5167a607a7b upstream.

Checking that we are not missing any `// SAFETY` comments in our `unsafe`
blocks is something we have wanted to do for a long time, as well as
cleaning up the remaining cases that were not documented [1].

Back when Rust for Linux started, this was something that could have
been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0,
Clippy implemented the `undocumented_unsafe_blocks` lint [2].

Even though the lint has a few false positives, e.g. in some cases where
attributes appear between the comment and the `unsafe` block [3], there
are workarounds and the lint seems quite usable already.

Thus enable the lint now.

We still have a few cases to clean up, so just allow those for the moment
by writing a `TODO` comment -- some of those may be good candidates for
new contributors.

Link: https://github.com/Rust-for-Linux/linux/issues/351 [1]
Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2]
Link: https://github.com/rust-lang/rust-clippy/issues/13189 [3]
Reviewed-by: Alice Ryhl 
Reviewed-by: Trevor Gross 
Tested-by: Gary Guo 
Reviewed-by: Gary Guo 
Link: https://lore.kernel.org/r/20240904204347.168520-5-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: kernel: fix typos in code comments

2024-08-21T11:29:36+00:00

Fix spelling mistakes in code comments.

Signed-off-by: Michael Vetter 
Reviewed-by: Alice Ryhl 
Reviewed-by: Benno Lossin 
Link: https://lore.kernel.org/r/20240819205731.2163-1-jubalh@iodoru.org
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda

rust: init: change the generated name of guard variables

2024-05-05T16:05:00+00:00

The initializers created by the `[try_][pin_]init!` macros utilize the
guard pattern to drop already initialized fields, when initialization
fails mid-way. These guards are generated to have the same name as the
field that they handle. To prevent namespacing issues [1] when the
field name is the same as e.g. a constant name, add `__` as a prefix
and `_guard` as the suffix.

[ Gary says:

   "Here's the simplified example:

    ```
    macro_rules! f {
        () => {
            let a = 1;
            let _: u32 = a;
        }
    }

    const a: u64 = 1;

    fn main() {
        f!();
    }
    ```

    The `a` in `f` have a different hygiene so normally it is scoped to the
    macro expansion and wouldn't escape. Interestingly a constant is still
    preferred despite the hygiene so constants escaped into the macro,
    leading to the error."

  - Miguel ]

Signed-off-by: Benno Lossin 
Reviewed-by: Boqun Feng 
Reviewed-by: Alice Ryhl 
Link: https://lore.kernel.org/rust-for-linux/1e8a2a1f-abbf-44ba-8344-705a9cbb1627@proton.me/ [1]
Link: https://lore.kernel.org/r/20240403194321.88716-1-benno.lossin@proton.me
[ Added Benno's link and Gary's simplified example. - Miguel ]
Signed-off-by: Miguel Ojeda

rust: macros: allow generic parameter default values in `#[pin_data]`

2024-04-07T20:03:42+00:00

Add support for generic parameters defaults in `#[pin_data]` by using
the newly introduced `decl_generics` instead of the `impl_generics`.

Before this would not compile:

    #[pin_data]
    struct Foo {
        // ...
    }

because it would be expanded to this:

    struct Foo {
        // ...
    }

    const _: () = {
        struct __ThePinData {
            __phantom: ::core::marker::PhantomData) -> Foo>,
        }
        impl ::core::clone::Clone for __ThePinData {
            fn clone(&self) -> Self {
                *self
            }
        }

        // [...] rest of expansion omitted
    };

The problem is with the `impl`, since that is
invalid Rust syntax. It should not mention the default value at all,
since default values only make sense on type definitions.

The new `impl_generics` do not contain the default values, thus
generating correct Rust code.

This is used by the next commit that puts `#[pin_data]` on
`kernel::workqueue::Work`.

Signed-off-by: Benno Lossin 
Reviewed-by: Martin Rodriguez Reboredo 
Reviewed-by: Gary Guo 
Reviewed-by: Alice Ryhl 
Tested-by: Alice Ryhl 
Link: https://lore.kernel.org/r/20240309155243.482334-2-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda