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

[Philipp Stanner <phasta@mailbox.org>]

On Tue, 2026-06-09 at 10:02 +0200, Christian König wrote:
> On 6/8/26 18:16, Boris Brezillon wrote:
> > - calling with the lock held in the new places is not causing a
> >   deadlock
> 
> Yeah, exactly that.
> 
> For example the set_deadline() is intentionally not called with the
> fence lock held because that won't work for some use cases.
> 
> The problem when you call ops with a lock held is always that this
> lock then becomes the outermost look held. In other words when you
> for example want to grab a power management lock to implement the
> deadline feature the framework enforces an order between the two
> locks which isn't desired.

A deadlock can only happen if that power management routine also
attempts to take the fence lock. Or maybe the fence ctx lock.

Why would it want to do that? What does it want to signal? I suppose in
case of a close enough deadline you will do a firmware call to shovel
some more coals into the kettle.

The only GPU driver implementing it seems MSM anyways?


P.