On Mon Jun 8, 2026 at 5:17 PM CEST, Philipp Stanner wrote: > On Mon, 2026-06-08 at 17:01 +0200, Boris Brezillon wrote: >> On Mon, 8 Jun 2026 16:24:37 +0200 >> Philipp Stanner <[email protected]> wrote: >> >> > @@ -1020,11 +1024,20 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout); >> > void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) >> > { >> > const struct dma_fence_ops *ops; >> > + unsigned long flags; >> > >> > rcu_read_lock(); >> > ops = rcu_dereference(fence->ops); >> > - if (ops && ops->set_deadline && !dma_fence_is_signaled(fence)) >> > + if (!ops || !ops->set_deadline) { >> > + rcu_read_unlock(); >> > + return; >> > + } >> > + >> > + dma_fence_lock_irqsave(fence, flags); >> > + if (!dma_fence_is_signaled_locked(fence)) >> > ops->set_deadline(fence, deadline); >> >> You can't take the fence lock around ->set_deadline(), otherwise you'll >> deadlock here [1] or here [2]. >> >> > + >> > + dma_fence_unlock_irqrestore(fence, flags); >> > rcu_read_unlock(); >> > } >> >> >> [1]https://elixir.bootlin.com/linux/v7.0.11/source/drivers/dma-buf/sw_sync.c#L182 >> [2]https://elixir.bootlin.com/linux/v7.0.11/source/drivers/gpu/drm/msm/msm_fence.c#L139 > > > If we'd port these (and maybe some we have overlooked) simultaneously, > they could completely drop their separate locking. > > The fact that other parties were forced to take the fence lock in their > callbacks (and even 100% of the functions' code) actually proves that > this RFC is probably a good idea and callback-calls should be guarded > by the fence lock :]
I think I looked into this recently and IIRC it indeed seems like all implementors of set_deadline() take the lock within their callback.
