linux-stable.git/rust, branch v6.12.90

rust: pin-init: fix incorrect accessor reference lifetime

2026-05-17T15:14:34+00:00

commit 68bf102226cf2199dc609b67c1e847cad4de4b57 upstream

When a field has been initialized, `init!`/`pin_init!` create a reference
or pinned reference to the field so it can be accessed later during the
initialization of other fields. However, the reference it created is
incorrectly `&'static` rather than just the scope of the initializer.

This means that you can do

    init!(Foo {
        a: 1,
        _: {
            let b: &'static u32 = a;
        }
    })

which is unsound.

This is caused by `&mut (*$slot).$ident`, which actually allows arbitrary
lifetime, so this is effectively `'static`.

Fix it by adding `let_binding` method on `DropGuard` to shorten lifetime.
This results in exactly what we want for these accessors. The safety and
invariant comments of `DropGuard` have been reworked; instead of reasoning
about what caller can do with the guard, express it in a way that the
ownership is transferred to the guard and `forget` takes it back, so the
unsafe operations within the `DropGuard` can be more easily justified.

Assisted-by: Claude:claude-3-opus
Signed-off-by: Gary Guo 
Signed-off-by: Greg Kroah-Hartman

rust: init: fix `clippy::undocumented_unsafe_blocks` warnings

2026-05-07T04:09:25+00:00

The stable backport in commit acc105db0826 ("rust: pin-init:
add references to previously initialized fields") introduced some
`clippy::undocumented_unsafe_blocks` warnings [1], e.g.

    error: unsafe block missing a safety comment
        --> rust/kernel/init/macros.rs:1015:25

As well as:

    --> rust/kernel/init/macros.rs:1243:45
    --> rust/kernel/init/macros.rs:1286:22
    --> rust/kernel/init/macros.rs:1374:45

After discussing it with Benno and Gary, we decided to clean the build
log by doing a minimal targeted stable commit.

Thus, depending on the case:

  - Reorder the attributes so that the existing `// SAFETY:` comments
    may be seen by Clippy.

  - Add a placeholder `// SAFETY: TODO.` comment.

Cc: Benno Lossin 
Cc: Gary Guo 
Fixes: acc105db0826 ("rust: pin-init: add references to previously initialized fields")
Link: https://lore.kernel.org/stable/20260421111111.57059-1-ojeda@kernel.org/ [1]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

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: kunit: fix warning when !CONFIG_PRINTK

2026-03-13T16:20:40+00:00

[ Upstream commit 7dd34dfc8dfa92a7244242098110388367996ac3 ]

If `CONFIG_PRINTK` is not set, then the following warnings are issued
during build:

  warning: unused variable: `args`
    --> ../rust/kernel/kunit.rs:16:12
    |
  16 | pub fn err(args: fmt::Arguments<'_>) {
    |            ^^^^ help: if this is intentional, prefix it with an underscore: `_args`
    |
    = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

  warning: unused variable: `args`
    --> ../rust/kernel/kunit.rs:32:13
    |
  32 | pub fn info(args: fmt::Arguments<'_>) {
    |             ^^^^ help: if this is intentional, prefix it with an underscore: `_args`

Fix this by adding a no-op assignment using `args` when `CONFIG_PRINTK`
is not set.

Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones")
Signed-off-by: Alexandre Courbot 
Reviewed-by: Alice Ryhl 
Reviewed-by: David Gow 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

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: rbtree: fix documentation typo in CursorMut peek_next method

2026-02-06T15:55:44+00:00

commit 45f6aed8a835ee2bdd0a5d5ee626a91fe285014f upstream.

The peek_next method's doc comment incorrectly stated it accesses the
"previous" node when it actually accesses the next node.

Fix the documentation to accurately reflect the method's behavior.

Fixes: 98c14e40e07a ("rust: rbtree: add cursor")
Reviewed-by: Alice Ryhl 
Signed-off-by: Hang Shu 
Reported-by: Miguel Ojeda 
Closes: https://github.com/Rust-for-Linux/linux/issues/1205
Cc: stable@vger.kernel.org
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20251107093921.3379954-1-m18080292938@163.com
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

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