[PATCH] dma-buf/dma-fence: Signal all callbacks from dma_fence_release()

Christian König deathsimple at vodafone.de
Sun Aug 13 13:04:29 UTC 2017


Am 11.08.2017 um 19:01 schrieb Chris Wilson:
> This is an illegal scenario, to free the fence whilst there are pending
> callbacks. Currently, we emit a WARN and then cast aside the callbacks
> leaving them dangling. Alternatively, we could set an error on the fence
> and then signal fence so that any dependency chains from the fence can
> be tidied up, and if they care they can check for the error.
>
> The question is whether or not the cure is worse than the disease
> (premature fence signaling is never pretty).
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>

Not sure if -EDEADLK is the best error code, but in general the approach 
sounds like the least evil to me.

Patch is Reviewed-by: Christian König <christian.koenig at amd.com>.

> ---
>   drivers/dma-buf/dma-fence.c | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 9a302799040e..ed311edbeefa 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -172,7 +172,19 @@ void dma_fence_release(struct kref *kref)
>   
>   	trace_dma_fence_destroy(fence);
>   
> -	WARN_ON(!list_empty(&fence->cb_list));
> +	if (WARN_ON(!list_empty(&fence->cb_list))) {
> +		unsigned long flags;
> +
> +		/*
> +		 * This should never happen, but if it does make sure that we
> +		 * don't leave chains dangling. We set the error flag first
> +		 * so that the callbacks know this signal is due to an error.
> +		 */
> +		spin_lock_irqsave(fence->lock, flags);
> +		fence->error = -EDEADLK;
> +		dma_fence_signal_locked(fence);
> +		spin_unlock_irqrestore(fence->lock, flags);
> +	}
>   
>   	if (fence->ops->release)
>   		fence->ops->release(fence);




More information about the dri-devel mailing list