[GIT PULL] pin-init changes for v7.3-rc1

[GIT PULL] pin-init changes for v7.3-rc1

[Gary Guo]

Hi Miguel,

Still more of refactors this cycle and not much feature updates. Tuple struct
still doesn't made it as there are some complexity related to `#[cfg]`s, but
the cfg-related internal refactoring are picked so hopefully we can land it the
next one.

I did a late rebase today to rename the API based on Benno's feedback. It does
made it into today's linux-next (2026-08-05). Feel free to wait for a few more
rounds before pulling if you see fit.

Best,
Gary

The following changes since commit a13c140cc289c0b7b3770bce5b3ad42ab35074aa:

  Linux 7.2-rc3 (2026-07-12 14:16:39 -0700)

are available in the Git repository at:

  https://github.com/Rust-for-Linux/linux.git tags/pin-init-v7.3

for you to fetch changes up to 1e26aea0355ad2afa1ccbc62885c01f5bcfc58ca:

  rust: pin-init: add `#[inline]` to small functions (2026-08-05 11:36:18 +0100)

----------------------------------------------------------------
User visible changes:

- Merge the `__pinned_init` and `__init` methods and make `Init` become a marker trait.

- Introduce public APIs `raw_init` and `raw_try_init` to prevent user from needing to invoke the internal `__pinned_init`/`__init` methods.

- Emit errors for duplicate `#[pin]` attributes.

- Link `Zeroable::zeroed` and `pin_init::zeroed` in documentation.

Other changes:

- Fix unwind safety issues.

- Clean up lint `allow` and `expect`s.

- Overhaul `#[cfg]` handling to pave the way for tuple struct and self referential structs.

- Mark many functions are `#[inline]` for better codegen with `-C opt-level=s` (CC_OPTIMIZE_FOR_SIZE).

----------------------------------------------------------------
Gary Guo (11):
      rust: pin-init: examples: fix incorrect drop
      rust: pin-init: remove redundant clippy expects in doc tests
      rust: pin-init: internal: remove `allow` and `expect`s that don't fire
      rust: pin-init: internal: generate brace in macro for init code blocks
      rust: pin-init: internal: rework how `#[pin_data]` handles cfg
      rust: pin-init: examples: use `Wrapper::pin_init` instead of manual reimplementation
      rust: pin-init: merge `__pinned_init` and `__init`
      rust: pin-init: add `raw_init` and `raw_try_init` and recommend over `__init`
      rust: treewide: replace `__pinned_init` with `raw_[try_]init`
      rust: pin-init: remove `__pinned_init` method for `cfg(kernel)`
      rust: pin-init: add `#[inline]` to small functions

Luiz Georg (1):
      rust: pin-init: internal: error on duplicate `#[pin]` attribute

Mirko Adzic (2):
      rust: pin-init: make `[pin_]init_array_from_fn` unwind safe
      rust: pin-init: make `[pin_]chain` unwind safe

Nicolás Antinori (2):
      rust: pin-init: docs: link `Zeroable::zeroed` and `pin_init::zeroed` in documentation
      rust: pin-init: mark `pin_init::zeroed` and `Zeroable::zeroed` as `#[inline]`

 drivers/gpu/nova-core/gsp/cmdq.rs      |   4 +-
 rust/kernel/alloc/kbox.rs              |   8 +-
 rust/kernel/dma.rs                     |  10 +-
 rust/kernel/drm/device.rs              |   2 +-
 rust/kernel/drm/gpuvm/va.rs            |   2 +-
 rust/kernel/drm/gpuvm/vm_bo.rs         |   2 +-
 rust/kernel/init.rs                    |   6 +-
 rust/kernel/pwm.rs                     |   2 +-
 rust/kernel/sync/arc.rs                |   8 +-
 rust/kernel/types.rs                   |   8 +-
 rust/macros/module.rs                  |   2 +-
 rust/pin-init/examples/mutex.rs        |  11 +-
 rust/pin-init/examples/static_init.rs  |  10 +-
 rust/pin-init/internal/src/init.rs     |   8 +-
 rust/pin-init/internal/src/pin_data.rs |  94 +++++++---
 rust/pin-init/src/__internal.rs        |  13 +-
 rust/pin-init/src/alloc.rs             |  10 +-
 rust/pin-init/src/lib.rs               | 333 +++++++++++++++++++--------------
 18 files changed, 319 insertions(+), 214 deletions(-)

Re: [GIT PULL] pin-init changes for v7.3-rc1

[Miguel Ojeda]

On Wed, 05 Aug 2026 20:00:07 +0100 Gary Guo <gary@kernel.org> wrote:
>
> Still more of refactors this cycle and not much feature updates. Tuple struct
> still doesn't made it as there are some complexity related to `#[cfg]`s, but
> the cfg-related internal refactoring are picked so hopefully we can land it the
> next one.
>
> I did a late rebase today to rename the API based on Benno's feedback. It does
> made it into today's linux-next (2026-08-05). Feel free to wait for a few more
> rounds before pulling if you see fit.

Thanks Gary -- we will need this on the merge commit in linux-next due
to the changes from driver-core-next (Cc'ing Mark):

diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
index c0cd24481ee3..a4927452016e 100644
--- a/rust/kernel/serdev.rs
+++ b/rust/kernel/serdev.rs
@@ -197,7 +197,7 @@ extern "C" fn probe_callback(sdev: *mut bindings::serdev_device) -> kernel::ffi:
             // SAFETY:
             // - `driver.as_mut_ptr()` is a valid pointer to uninitialized data.
             // - `private_data.driver` is pinned.
-            let result = unsafe { data.__pinned_init(driver.as_mut_ptr()) };
+            let result = unsafe { pin_init::raw_try_init(driver.as_mut_ptr(), data) };

             *active = result.is_ok();

Cheers,
Miguel

Re: [GIT PULL] pin-init changes for v7.3-rc1

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Thu, Aug 06, 2026 at 07:01:01PM +0200, Miguel Ojeda wrote:

> Thanks Gary -- we will need this on the merge commit in linux-next due
> to the changes from driver-core-next (Cc'ing Mark):

The merge commit for what?

> 
> diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
> index c0cd24481ee3..a4927452016e 100644
> --- a/rust/kernel/serdev.rs
> +++ b/rust/kernel/serdev.rs
> @@ -197,7 +197,7 @@ extern "C" fn probe_callback(sdev: *mut bindings::serdev_device) -> kernel::ffi:
>              // SAFETY:
>              // - `driver.as_mut_ptr()` is a valid pointer to uninitialized data.
>              // - `private_data.driver` is pinned.
> -            let result = unsafe { data.__pinned_init(driver.as_mut_ptr()) };
> +            let result = unsafe { pin_init::raw_try_init(driver.as_mut_ptr(), data) };
> 
>              *active = result.is_ok();
> 
> Cheers,
> Miguel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] pin-init changes for v7.3-rc1

[Miguel Ojeda]

On Thu, Aug 6, 2026 at 7:05 PM Mark Brown <broonie@kernel.org> wrote:
>
> The merge commit for what?

I think you merge driver-core-next after the rust-next/pin-init ones,
so I assume in the driver-core-next one, right?

Cheers,
Miguel

Re: [GIT PULL] pin-init changes for v7.3-rc1

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

On Thu, Aug 06, 2026 at 07:09:58PM +0200, Miguel Ojeda wrote:
> On Thu, Aug 6, 2026 at 7:05 PM Mark Brown <broonie@kernel.org> wrote:

> > The merge commit for what?

> I think you merge driver-core-next after the rust-next/pin-init ones,
> so I assume in the driver-core-next one, right?

Yes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] pin-init changes for v7.3-rc1

[Miguel Ojeda]

On Thu, Aug 6, 2026 at 7:22 PM Mark Brown <broonie@kernel.org> wrote:
>
> Yes.

Thanks!

(Please let me know if you prefer a proper patch etc., of course)

Cheers,
Miguel

Re: [GIT PULL] pin-init changes for v7.3-rc1

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On Thu, Aug 06, 2026 at 07:53:41PM +0200, Miguel Ojeda wrote:

> (Please let me know if you prefer a proper patch etc., of course)

In general that's going to be easier and more reliable than copying me
into the middle of a thread with a patch buried in the middle of it,
there's a chance that if a subject line isn't obviously relevant I might
just drop an email unread.  I get copies on *lots* of stuff.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] pin-init changes for v7.3-rc1

[Miguel Ojeda]

On Thu, Aug 6, 2026 at 8:21 PM Mark Brown <broonie@kernel.org> wrote:
>
> In general that's going to be easier and more reliable than copying me
> into the middle of a thread with a patch buried in the middle of it,
> there's a chance that if a subject line isn't obviously relevant I might
> just drop an email unread.  I get copies on *lots* of stuff.

Yeah, I can imagine -- sent now:

  https://lore.kernel.org/linux-next/20260807074729.108159-1-ojeda@kernel.org/

Thanks!

(I think you may want `-next` inside the brackets -- I can do that)

Cheers,
Miguel

Re: [GIT PULL] pin-init changes for v7.3-rc1

[Gary Guo]

On Thu Aug 6, 2026 at 6:01 PM BST, Miguel Ojeda wrote:
> On Wed, 05 Aug 2026 20:00:07 +0100 Gary Guo <gary@kernel.org> wrote:
>>
>> Still more of refactors this cycle and not much feature updates. Tuple struct
>> still doesn't made it as there are some complexity related to `#[cfg]`s, but
>> the cfg-related internal refactoring are picked so hopefully we can land it the
>> next one.
>>
>> I did a late rebase today to rename the API based on Benno's feedback. It does
>> made it into today's linux-next (2026-08-05). Feel free to wait for a few more
>> rounds before pulling if you see fit.
>
> Thanks Gary -- we will need this on the merge commit in linux-next due
> to the changes from driver-core-next (Cc'ing Mark):
>
> diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
> index c0cd24481ee3..a4927452016e 100644
> --- a/rust/kernel/serdev.rs
> +++ b/rust/kernel/serdev.rs
> @@ -197,7 +197,7 @@ extern "C" fn probe_callback(sdev: *mut bindings::serdev_device) -> kernel::ffi:
>              // SAFETY:
>              // - `driver.as_mut_ptr()` is a valid pointer to uninitialized data.
>              // - `private_data.driver` is pinned.
> -            let result = unsafe { data.__pinned_init(driver.as_mut_ptr()) };
> +            let result = unsafe { pin_init::raw_try_init(driver.as_mut_ptr(), data) };
>
>              *active = result.is_ok();
>
> Cheers,
> Miguel

Thanks Miguel, the semantic conflict resolution looks correct to me.

Best,
Gary