[PATCH 4/4] dma-fence: Always execute signal callbacks

[Koenig, Christian]

Am 10.08.19 um 17:34 schrieb Chris Wilson:
> Allow for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the signaling mechanism around every fence.
> (The cost of interrupts is too darn high, to revive an old meme.)
> This means that we may have a cb_list even if the signaling bit is not
> enabled, so always notify the callbacks.
>
> The cost is that dma_fence_signal() must always acquire the spinlock to
> ensure that the cb_list is flushed.
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> ---
>   drivers/dma-buf/dma-fence.c | 8 +++-----
>   1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 027a6a894abd..ab4a456bba04 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -170,11 +170,9 @@ int dma_fence_signal(struct dma_fence *fence)
>   
>   	__dma_fence_signal__timestamp(fence, ktime_get());
>   
> -	if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
> -		spin_lock_irqsave(fence->lock, flags);
> -		__dma_fence_signal__notify(fence);
> -		spin_unlock_irqrestore(fence->lock, flags);
> -	}
> +	spin_lock_irqsave(fence->lock, flags);
> +	__dma_fence_signal__notify(fence);
> +	spin_unlock_irqrestore(fence->lock, flags);

If we now always grab the spinlock anyway I suggest to rather merge 
dma_fence_signal and dma_fence_signal_locked.

Christian.

>   	return 0;
>   }
>   EXPORT_SYMBOL(dma_fence_signal);