Re: [RFC PATCH] dma-fence: Fix races of fence callbacks versus destructors by locking

[Danilo Krummrich]

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 <phasta@xxxxxxxxxx> 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.