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.
