[PATCH] dma-buf: fix dma_fence_array_signaled v3

[Tvrtko Ursulin]

On 12/11/2024 12:19, Christian König wrote:
> The function silently assumed that signaling was already enabled for the
> dma_fence_array. This meant that without enabling signaling first we would
> never see forward progress.
> 
> Fix that by falling back to testing each individual fence when signaling
> isn't enabled yet.
> 
> v2: add the comment suggested by Boris why this is done this way
> v3: fix the underflow pointed out by Tvrtko
> 
> Signed-off-by: Christian König <christian.koenig at amd.com>
> Reviewed-by: Boris Brezillon <boris.brezillon at collabora.com>
> ---
>   drivers/dma-buf/dma-fence-array.c | 25 ++++++++++++++++++++++++-
>   1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c
> index 8a08ffde31e7..c3ffcc842c6f 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -103,10 +103,33 @@ static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
>   static bool dma_fence_array_signaled(struct dma_fence *fence)
>   {
>   	struct dma_fence_array *array = to_dma_fence_array(fence);
> +	int num_pending;
> +	unsigned int i;
>   
> -	if (atomic_read(&array->num_pending) > 0)
> +	/* We need to read num_pending before checking the enable_signal bit
> +	 * to avoid racing with the enable_signaling() implementation, which
> +	 * might decrement the counter, and cause a partial check.
> +	 *
> +	 * The !--num_pending check is here to account for the any_signaled case
> +	 * if we race with enable_signaling(), that means the !num_pending check
> +	 * in the is_signalling_enabled branch might be outdated (num_pending
> +	 * might have been decremented), but that's fine. The user will get the
> +	 * right value when testing again later.
> +	 */

Bonus points if you could please tweak to the same multi-line comment 
style as used in this file.

> +	num_pending = atomic_read(&array->num_pending);
> +	if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &array->base.flags)) {

I am not sure if a memory barrier would be useful in between these two 
to ensure no re-ordering. Saying this because Documentation/atomic_t.txt 
and atomic_bitops.txt suggest both atomic_read and test_bit are 
un-ordered, in which case it could be better to explicitly mark the 
expectation.

Regards,

Tvrtko

> +		if (num_pending <= 0)
> +			goto signal;
>   		return false;
> +	}
> +
> +	for (i = 0; i < array->num_fences; ++i) {
> +		if (dma_fence_is_signaled(array->fences[i]) && !--num_pending)
> +			goto signal;
> +	}
> +	return false;
>   
> +signal:
>   	dma_fence_array_clear_pending_error(array);
>   	return true;
>   }