All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Danilo Krummrich" <dakr@kernel.org>
Cc: dri-devel@lists.freedesktop.org, ojeda@kernel.org,
	"Alexandre Courbot" <acourbot@nvidia.com>
Subject: Re: [PATCH v3 3/7] rust: auxiliary: add registration_data_with() for ForLt types
Date: Thu, 18 Jun 2026 23:22:14 +0000	[thread overview]
Message-ID: <20260618232215.169481F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260618230834.812007-4-dakr@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Small forwarding functions in abstractions are missing `#[inline]` annotations.
--

commit 703db32948a8690227e0f13e2618862778e2205c
Author: Danilo Krummrich <dakr@kernel.org>

rust: auxiliary: add registration_data_with() for ForLt types

This commit adds registration_data_with() to allow non-covariant ForLt
types to be registered by taking an HRTB closure, avoiding concrete lifetime
selection. It also extracts shared logic into a private
registration_data_pinned() helper and relaxes the Registration bound.

> diff --git a/rust/kernel/auxiliary.rs b/rust/kernel/auxiliary.rs
> index 40a0af74a8e5c..8013c0fcd82d8 100644
> --- a/rust/kernel/auxiliary.rs
> +++ b/rust/kernel/auxiliary.rs

[ ... ]

> @@ -300,17 +298,57 @@ pub fn registration_data<F: CovariantForLt + 'static>(&self) -> Result<Pin<&F::O

[ ... ]

> +    pub fn registration_data_with<F: ForLt + 'static, R>(
> +        &self,
> +        f: impl for<'a> FnOnce(Pin<&'a F::Of<'a>>) -> R,
> +    ) -> Result<R> {

[Severity: Low]
This isn't a bug, but according to the Rust subsystem guidelines, small or
forwarding functions in abstractions should be annotated with #[inline].
Should this newly added forwarding function have an #[inline] attribute?

> +        // SAFETY: The HRTB closure prevents the caller from smuggling in references with a
> +        // concrete short lifetime, making the round-trip from `'static` sound regardless of
> +        // variance.
> +        let pinned = unsafe { self.registration_data_pinned::<F>()? };
> +
> +        Ok(f(pinned))
> +    }

[ ... ]

> +    pub fn registration_data<F: CovariantForLt + 'static>(&self) -> Result<Pin<&F::Of<'_>>> {

[Severity: Low]
This isn't a bug, but since this function was modified to become a small
forwarding function to registration_data_pinned(), should it also receive
an #[inline] annotation to match the subsystem guidelines?

> +        // SAFETY: `CovariantForLt` guarantees covariance, which makes the lifetime shortening
> +        // from `'static` to `'_` performed by `registration_data_pinned` sound.
> +        unsafe { self.registration_data_pinned::<F>() }
>      }
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618230834.812007-1-dakr@kernel.org?part=3

  reply	other threads:[~2026-06-18 23:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18 23:08 [PATCH v3 0/7] ForLt/CovariantForLt split, auxiliary closure API and DevresLt Danilo Krummrich
2026-06-18 23:08 ` [PATCH v3 1/7] rust: types: rename ForLt to CovariantForLt Danilo Krummrich
2026-06-18 23:15   ` sashiko-bot
2026-06-18 23:08 ` [PATCH v3 2/7] rust: types: introduce ForLt base trait for CovariantForLt Danilo Krummrich
2026-06-18 23:08 ` [PATCH v3 3/7] rust: auxiliary: add registration_data_with() for ForLt types Danilo Krummrich
2026-06-18 23:22   ` sashiko-bot [this message]
2026-06-18 23:08 ` [PATCH v3 4/7] rust: auxiliary: sample: demonstrate ForLt with invariant Mutex type Danilo Krummrich
2026-06-18 23:21   ` sashiko-bot
2026-06-18 23:08 ` [PATCH v3 5/7] rust: devres: add DevresLt for ForLt-aware device resource access Danilo Krummrich
2026-06-18 23:21   ` sashiko-bot
2026-06-18 23:08 ` [PATCH v3 6/7] rust: pci: return DevresLt from Bar::into_devres() Danilo Krummrich
2026-06-18 23:08 ` [PATCH v3 7/7] rust: io: mem: return DevresLt from IoMem/ExclusiveIoMem::into_devres() Danilo Krummrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260618232215.169481F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.