On Tue, 2026-06-16 at 13:02 +0200, Danilo Krummrich wrote:
> On Tue Jun 16, 2026 at 10:28 AM CEST, Philipp Stanner wrote:
> > Changes since v1:
> 
> It seems that some of the comments from v1 [1][2] are not addressed, did you
> forget them?

yeah, a bunch of stuff might have slipped me. Mea culpa. Need to
address some more issues in v3 anyways; but wanted to present the rough
RCU idea here as a heads-up.

> 
> In particular the pin_init_from_closure() looks unnecessary and can probably
> replaced with something like (untested):
> 
>       let mut callback = Some(callback);
>       
>       try_pin_init!(Self {
>           cb <- Opaque::try_ffi_init(|ptr| {
>               // SAFETY: `fence.inner.get()` is a valid, initialized `struct 
> dma_fence`. `ptr`
>               // points to the `struct dma_fence_cb` field within the pinned 
> allocation, so it
>               // remains valid until `dma_fence_remove_callback()` in 
> `PinnedDrop` or until the
>               // callback fires.
>               let ret = unsafe {
>                   to_result(bindings::dma_fence_add_callback(
>                       fence.inner.get(),
>                       ptr,
>                       Some(Self::dma_fence_callback),
>                   ))
>               };
>               match ret {
>                   Ok(()) => Ok(()),
>                   Err(e) => {
>                       let cb_back = callback.take().expect("success path did 
> not run");
>                       if e == ENOENT {
>                           Err(CallbackError::AlreadySignaled(cb_back))
>                       } else {
>                           Err(CallbackError::Other(e))
>                       }
>                   }
>               }
>           }),
>           callback: callback.take().expect("error path did not run"),
>           fence: ARef::from(fence),
>       }? CallbackError<T>)
> 
> Please also see my previous comments regarding DriverFenceBorrow, it still 
> seems
> to miss the lifetime and it should probably use ManuallyDrop<DriverFence>.

ACK.

> 
> It also seems the patch series was created without --base, what's the base
> revision?

Branched out from drm-misc-next for development purposes (since it
heavily relies on dma-fence.c)

I can rebase on drm-rust-next for the next revision.

> 
> [1] https://lore.kernel.org/all/[email protected]/
> [2] https://lore.kernel.org/all/[email protected]/

Reply via email to