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 :] P.
