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

[Christian König]

On 6/9/26 07:52, Philipp Stanner wrote:
...
>>
>> In detail calling the callbacks without holding locks allows all implementations who need it to explicitly take locks in the order they want.
> 
> Didn't you say a few mails above that the implementation should not use
> the fence lock for its own purposes?

The usual use case the drivers have is this here:

dma_fence_lock_irqsave(fence, flags);
was_signaled = dma_fence_test_signaled(fence);
if (!was_signaled)
	dma_fence_signal(fence);
dma_fence_unlock_irqrestore(fence, flags);

if (!was_signaled)
	cleanup();

This is actually what you and me came up with for the KFD when we removed the return code for dma_fence_signal().

Taking the lock around the enable_signaling() callback has the exact same reason, preventing the fence from signaling between testing and calling dma_fence_signal(). The problem with that approach is that cleanup() now suddenly runs under the fence lock as well.

So you are left with few options: Either the fence lock is external, which we don't want because that make the fence non-independent, or cleanup() defers work to irq_work or work_structs, which creates numerous lifetime issues.

When enable_signaling would be independent of the fence lock we could avoid all of this and just use a normal spin_lock() for the cleanup.

Regards,
Christian.

> 
> 
> P.
> 
>>
>> If you call it with the lock held you enforce the fence lock the be the outermost lock.
>>
>> Regards,
>> Christian.