linux-stable.git/rust/pin-init, branch master

rust: pin-init: add `#[inline]` to small functions

2026-08-05T10:36:18+00:00

Currently `pin-init` crate is missing many inline annotations. They are all
generic so still get inlined in normal builds, but are not inlined in
`-C opt-level=s` build. Mark these functions as `#[inline]` so they are
considered for inlining regardless.

Signed-off-by: Gary Guo

rust: pin-init: remove `__pinned_init` method for `cfg(kernel)`

2026-08-05T10:36:18+00:00

Remove `__pinned_init` for kernel configuration, with all users gone.
Still perserve it temporarily as deprecated so other users have time to
move off it.

Link: https://patch.msgid.link/20260729-merge-init-v2-5-26adf47109e7@garyguo.net
Signed-off-by: Gary Guo

rust: pin-init: add `raw_init` and `raw_try_init` and recommend over `__init`

2026-08-05T10:36:16+00:00

The `__init` method is not designed to be a public API (existence of "__"
is a hint for this); but currently there is no other API that allows raw
initialization on pointers. Add `raw_init` and `raw_try_init` and recommend
people to use this instead if raw pointer initialization is needed.

Link: https://patch.msgid.link/20260729-merge-init-v2-3-26adf47109e7@garyguo.net
[ Renamed from `ptr_[try_]init` to `raw_[try_]init`. - Gary ]
Reviewed-by: Benno Lossin 
Signed-off-by: Gary Guo

rust: pin-init: merge `__pinned_init` and `__init`

2026-08-03T12:36:42+00:00

These functions have the same requirements and are also required to execute
the same code. Prevent duplication by merging them to the single function
and document the additional relaxation of `Init::__init` on both the merged
function and the safety requirement of `Init`.

The existing `__pinned_init` function is deprecated and kept for
compatibility for existing users. For `cfg(kernel)`, it is soft-deprecated
for now and will be removed when all users are migrated.

Link: https://patch.msgid.link/20260729-merge-init-v2-2-26adf47109e7@garyguo.net
Signed-off-by: Gary Guo

rust: pin-init: examples: use `Wrapper::pin_init` instead of manual reimplementation

2026-08-03T12:36:34+00:00

`UnsafeCell` gains the method via the extension trait `Wrapper`.

Link: https://patch.msgid.link/20260729-merge-init-v2-1-26adf47109e7@garyguo.net
Signed-off-by: Gary Guo

rust: pin-init: mark `pin_init::zeroed` and `Zeroable::zeroed` as `#[inline]`

2026-07-27T10:52:08+00:00

The `pin_init::zeroed` function is a trivial wrapper around
`unsafe { core::mem::zeroed() }`, whereas `Zeroable::zeroed` is a trivial
wrapper around `pin_init::zeroed`. Mark them both as `#[inline]` to avoid
generating unnecessary symbols for them.

Signed-off-by: Nicolás Antinori 
Signed-off-by: Gary Guo

rust: pin-init: docs: link `Zeroable::zeroed` and `pin_init::zeroed` in documentation

2026-07-27T10:52:08+00:00

Modify the comments in the `pin_init::zeroed` and `Zeroable::zeroed`
functions to cross-reference each other and make developers aware of both
options.

This also adapts the example code in `Zeroable::zeroed` doc comments to use
that function.

Suggested-by: Miguel Ojeda 
Link: https://lore.kernel.org/rust-for-linux/CANiq72kdCAyRUmXFcqQfkHpk1miG8Gagsn0_5U8p4WpKxv9d_g@mail.gmail.com/
Signed-off-by: Nicolás Antinori 
[ Fix link. - Gary ]
Signed-off-by: Gary Guo

rust: pin-init: internal: rework how `#[pin_data]` handles cfg

2026-07-27T10:52:08+00:00

Attribute macros are invoked without cfg being resolved. This adds quite a
bit complexity to the macro because all of the macro needs to be careful to
attach necessary cfgs. This becomes especially tricky for tuple structs.
Thus, it is convenient if cfgs are all resolved like derive macros.

The most optimal way to handle this is via `TokenStream::expand_expr`, but
that is still unstable. We can also create an internal derive macro and
transform the attribute macro invocation to be derive macro, but doing
requires us to serialize all extracted information in a form of helper
attributes; it would also make it more difficult if we want to make changes
to the struct (which the self-reference feature would need).

Implement an approach where we generate two cfg-gated macro invocations
with cfg resolved within the invocation. This would mean when the loop
falls through, all field cfgs are resolved, so remove all handling of
cfg_attrs for the rest of the macro.

Signed-off-by: Gary Guo

rust: pin-init: make `[pin_]chain` unwind safe

2026-07-13T11:11:44+00:00

Add a drop guard before the call to the chained closure so that the value
initialized by the first stage is dropped if the closure errors or panics;
`mem::forget` the guard on success.

The previous code only ran cleanup on the explicit error path, leaking the
first-stage value if the chained closure panicked.

Reported-by: Gary Guo 
Closes: https://github.com/Rust-for-Linux/pin-init/issues/136
Suggested-by: Gary Guo 
Signed-off-by: Mirko Adzic 
Link: https://patch.msgid.link/20260710-pin-init-sync-v1-7-8fa16cde87ae@garyguo.net
[ Fix Clippy missing safety comment false positive when `slot` and `guard`
  creation are merged in a single line. - Gary ]
Signed-off-by: Gary Guo

rust: pin-init: make `[pin_]init_array_from_fn` unwind safe

2026-07-13T11:11:29+00:00

The previous code only ran cleanup on the explicit error path. If the per-
element initializer panicked partway through, the elements already written
into the array would be leaked: their `Drop` impls would never run. This
violates the pinning requirement.

Fix the unwind safety issue by adding a guard type that drops element on
both error and panic path.

To avoid having to duplicate code between `pin_init_array_from_fn` and the
non-pin variant, extract the code to a shared `ArrayInit` type; this type
is internal and not visible via API.

Reported-by: Gary Guo 
Closes: https://github.com/Rust-for-Linux/pin-init/issues/136
Signed-off-by: Mirko Adzic 
Link: https://patch.msgid.link/20260710-pin-init-sync-v1-6-8fa16cde87ae@garyguo.net
[ Split guard type and the initializer type, move the guard type to be
  within __pinned_init. - Gary ]
Co-developed-by: Gary Guo 
Signed-off-by: Gary Guo