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 <[email protected]> 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/[email protected]?part=1
