All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Philipp Stanner" <phasta@kernel.org>
Cc: ojeda@kernel.org, gary@garyguo.net, media-ci@linuxtv.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH v4 1/3] rust: DmaFence: remove static lifetime
Date: Tue, 29 Sep 2026 10:59:52 +0000	[thread overview]
Message-ID: <20260929105952.D45301F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260929104703.934128-3-phasta@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] rust: dma_fence: missing safety doc for FenceCallbackRegistration::new()
--

commit 6cb68d1acd60ccf038d3c22a96a083dfc30b1a48
Author: Philipp Stanner <phasta@kernel.org>

rust: DmaFence: remove static lifetime

This commit removes the static lifetime requirement for FenceCallback,
allowing callbacks to hold non-static references. It also updates
FenceCallbackRegistration::new to be unsafe to account for this change.

> diff --git a/rust/kernel/dma_buf/dma_fence.rs b/rust/kernel/dma_buf/dma_fence.rs
> index 18a43e1bb442f..eef2b9e93f356 100644
> --- a/rust/kernel/dma_buf/dma_fence.rs
> +++ b/rust/kernel/dma_buf/dma_fence.rs

[ ... ]

> @@ -326,7 +326,7 @@ impl<T: FenceCallback> FenceCallbackRegistration<T> {
>      /// On success the callback is pinned in place and will fire when the fence
>      /// signals. On `AlreadySignaled` the callback is returned to the caller so
>      /// that owned resources can be reclaimed.
> -    pub fn new<'a>(fence: &'a Fence, callback: T) -> impl PinInit<Self, CallbackError<T>> + 'a
> +    pub unsafe fn new<'a>(fence: &'a Fence, callback: T) -> impl PinInit<Self, CallbackError<T>> + 'a

[Severity: Medium]
Are we missing the safety documentation for this newly marked unsafe function?

If a developer calls FenceCallbackRegistration::new with a callback holding
local stack references and leaks the registration, could this result in a
use-after-free when the C backend eventually invokes the callback?

Should there be an explicit safety contract explaining this anti-leak
precondition to prevent bypassing memory safety guarantees?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929104703.934128-2-phasta@kernel.org?part=1

  reply	other threads:[~2026-09-29 10:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29 10:47 [RFC PATCH v4 0/3] rust: Add drm::JobQueue Philipp Stanner
2026-09-29 10:47 ` [RFC PATCH v4 1/3] rust: DmaFence: remove static lifetime Philipp Stanner
2026-09-29 10:59   ` sashiko-bot [this message]
2026-09-29 10:47 ` [RFC PATCH v4 2/3] rust: DmaFence: Implement Deref for FenceContext Philipp Stanner
2026-09-29 10:55   ` sashiko-bot
2026-09-29 10:47 ` [RFC PATCH v4 3/3] rust: drm: Add JobQueue Philipp Stanner
2026-09-29 11:02   ` sashiko-bot

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=20260929105952.D45301F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=media-ci@linuxtv.org \
    --cc=ojeda@kernel.org \
    --cc=phasta@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.