[RFC,1/2] dma-fence: Avoid establishing a locking order between fence classes

Commit Message

Thomas Hellstrom Nov. 30, 2021, 12:19 p.m. UTC

The locking order for taking two fence locks is implicitly defined in
at least two ways in the code:

1) Fence containers first and other fences next, which is defined by
the enable_signaling() callbacks of dma_fence_chain and
dma_fence_array.
2) Reverse signal order, which is used by __i915_active_fence_set().

Now 1) implies 2), except for the signal_on_any mode of dma_fence_array
and 2) does not imply 1), and also 1) makes locking order between
different containers confusing.

Establish 2) and fix up the signal_on_any mode by calling
enable_signaling() on such fences unlocked at creation.

Cc: [e-mail]
Cc: [e-mail]
Cc: Christian König <[e-mail]>
Signed-off-by: Thomas Hellström <[e-mail]>
---
 drivers/dma-buf/dma-fence-array.c | 13 +++--
 drivers/dma-buf/dma-fence-chain.c |  3 +-
 drivers/dma-buf/dma-fence.c       | 79 +++++++++++++++++++++----------
 include/linux/dma-fence.h         |  3 ++
 4 files changed, 69 insertions(+), 29 deletions(-)

Comments

Maarten Lankhorst Nov. 30, 2021, 12:25 p.m. UTC | #1

On 30-11-2021 13:19, Thomas Hellström wrote:
> The locking order for taking two fence locks is implicitly defined in
> at least two ways in the code:
>
> 1) Fence containers first and other fences next, which is defined by
> the enable_signaling() callbacks of dma_fence_chain and
> dma_fence_array.
> 2) Reverse signal order, which is used by __i915_active_fence_set().
>
> Now 1) implies 2), except for the signal_on_any mode of dma_fence_array
> and 2) does not imply 1), and also 1) makes locking order between
> different containers confusing.
>
> Establish 2) and fix up the signal_on_any mode by calling
> enable_signaling() on such fences unlocked at creation.
>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: Christian König <[e-mail]>
> Signed-off-by: Thomas Hellström <[e-mail]>
> ---
>  drivers/dma-buf/dma-fence-array.c | 13 +++--
>  drivers/dma-buf/dma-fence-chain.c |  3 +-
>  drivers/dma-buf/dma-fence.c       | 79 +++++++++++++++++++++----------
>  include/linux/dma-fence.h         |  3 ++
>  4 files changed, 69 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c
> index 3e07f961e2f3..0322b92909fe 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -84,8 +84,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
>  		 * insufficient).
>  		 */
>  		dma_fence_get(&array->base);
> -		if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
> -					   dma_fence_array_cb_func)) {
> +		if (dma_fence_add_callback_nested(array->fences[i], &cb[i].cb,
> +						  dma_fence_array_cb_func)) {
>  			int error = array->fences[i]->error;
>  
>  			dma_fence_array_set_pending_error(array, error);
> @@ -158,6 +158,7 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>  {
>  	struct dma_fence_array *array;
>  	size_t size = sizeof(*array);
> +	struct dma_fence *fence;
>  
>  	/* Allocate the callback structures behind the array. */
>  	size += num_fences * sizeof(struct dma_fence_array_cb);
> @@ -165,8 +166,9 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>  	if (!array)
>  		return NULL;
>  
> +	fence = &array->base;
>  	spin_lock_init(&array->lock);
> -	dma_fence_init(&array->base, &dma_fence_array_ops, &array->lock,
> +	dma_fence_init(fence, &dma_fence_array_ops, &array->lock,
>  		       context, seqno);
>  	init_irq_work(&array->work, irq_dma_fence_array_work);
>  
> @@ -174,7 +176,10 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>  	atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
>  	array->fences = fences;
>  
> -	array->base.error = PENDING_ERROR;
> +	fence->error = PENDING_ERROR;
> +
> +	if (signal_on_any)
> +		dma_fence_enable_sw_signaling(fence);
>  
>  	return array;
>  }
> diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c
> index 1b4cb3e5cec9..0518e53880f6 100644
> --- a/drivers/dma-buf/dma-fence-chain.c
> +++ b/drivers/dma-buf/dma-fence-chain.c
> @@ -152,7 +152,8 @@ static bool dma_fence_chain_enable_signaling(struct dma_fence *fence)
>  		struct dma_fence *f = chain ? chain->fence : fence;
>  
>  		dma_fence_get(f);
> -		if (!dma_fence_add_callback(f, &head->cb, dma_fence_chain_cb)) {
> +		if (!dma_fence_add_callback_nested(f, &head->cb,
> +						   dma_fence_chain_cb)) {
>  			dma_fence_put(fence);
>  			return true;
>  		}
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 066400ed8841..90a3d5121746 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -610,6 +610,37 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence)
>  }
>  EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
>  
> +static int __dma_fence_add_callback(struct dma_fence *fence,
> +				    struct dma_fence_cb *cb,
> +				    dma_fence_func_t func,
> +				    int nest_level)
> +{
> +	unsigned long flags;
> +	int ret = 0;
> +
> +	if (WARN_ON(!fence || !func))
> +		return -EINVAL;
> +
> +	if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> +		INIT_LIST_HEAD(&cb->node);
> +		return -ENOENT;
> +	}
> +
> +	spin_lock_irqsave_nested(fence->lock, flags, 0);
Forgot to hook up nest_level here?
> +
> +	if (__dma_fence_enable_signaling(fence)) {
> +		cb->func = func;
> +		list_add_tail(&cb->node, &fence->cb_list);
> +	} else {
> +		INIT_LIST_HEAD(&cb->node);
> +		ret = -ENOENT;
> +	}
> +
> +	spin_unlock_irqrestore(fence->lock, flags);
> +
> +	return ret;
> +}
> +
>  /**
>   * dma_fence_add_callback - add a callback to be called when the fence
>   * is signaled
> @@ -635,33 +666,33 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
>  int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
>  			   dma_fence_func_t func)
>  {
> -	unsigned long flags;
> -	int ret = 0;
> -
> -	if (WARN_ON(!fence || !func))
> -		return -EINVAL;
> -
> -	if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> -		INIT_LIST_HEAD(&cb->node);
> -		return -ENOENT;
> -	}
> -
> -	spin_lock_irqsave(fence->lock, flags);
> -
> -	if (__dma_fence_enable_signaling(fence)) {
> -		cb->func = func;
> -		list_add_tail(&cb->node, &fence->cb_list);
> -	} else {
> -		INIT_LIST_HEAD(&cb->node);
> -		ret = -ENOENT;
> -	}
> -
> -	spin_unlock_irqrestore(fence->lock, flags);
> -
> -	return ret;
> +	return __dma_fence_add_callback(fence, cb, func, 0);
>  }
>  EXPORT_SYMBOL(dma_fence_add_callback);
>  

Other than that, I didn't investigate the nesting fails enough to say I can accurately review this. :)

~Maarten

Thomas Hellstrom Nov. 30, 2021, 12:31 p.m. UTC | #2

On 11/30/21 13:25, Maarten Lankhorst wrote:
> On 30-11-2021 13:19, Thomas Hellström wrote:
>> The locking order for taking two fence locks is implicitly defined in
>> at least two ways in the code:
>>
>> 1) Fence containers first and other fences next, which is defined by
>> the enable_signaling() callbacks of dma_fence_chain and
>> dma_fence_array.
>> 2) Reverse signal order, which is used by __i915_active_fence_set().
>>
>> Now 1) implies 2), except for the signal_on_any mode of dma_fence_array
>> and 2) does not imply 1), and also 1) makes locking order between
>> different containers confusing.
>>
>> Establish 2) and fix up the signal_on_any mode by calling
>> enable_signaling() on such fences unlocked at creation.
>>
>> Cc: [e-mail]
>> Cc: [e-mail]
>> Cc: Christian König <[e-mail]>
>> Signed-off-by: Thomas Hellström <[e-mail]>
>> ---
>>   drivers/dma-buf/dma-fence-array.c | 13 +++--
>>   drivers/dma-buf/dma-fence-chain.c |  3 +-
>>   drivers/dma-buf/dma-fence.c       | 79 +++++++++++++++++++++----------
>>   include/linux/dma-fence.h         |  3 ++
>>   4 files changed, 69 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c
>> index 3e07f961e2f3..0322b92909fe 100644
>> --- a/drivers/dma-buf/dma-fence-array.c
>> +++ b/drivers/dma-buf/dma-fence-array.c
>> @@ -84,8 +84,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
>>   		 * insufficient).
>>   		 */
>>   		dma_fence_get(&array->base);
>> -		if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
>> -					   dma_fence_array_cb_func)) {
>> +		if (dma_fence_add_callback_nested(array->fences[i], &cb[i].cb,
>> +						  dma_fence_array_cb_func)) {
>>   			int error = array->fences[i]->error;
>>   
>>   			dma_fence_array_set_pending_error(array, error);
>> @@ -158,6 +158,7 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>>   {
>>   	struct dma_fence_array *array;
>>   	size_t size = sizeof(*array);
>> +	struct dma_fence *fence;
>>   
>>   	/* Allocate the callback structures behind the array. */
>>   	size += num_fences * sizeof(struct dma_fence_array_cb);
>> @@ -165,8 +166,9 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>>   	if (!array)
>>   		return NULL;
>>   
>> +	fence = &array->base;
>>   	spin_lock_init(&array->lock);
>> -	dma_fence_init(&array->base, &dma_fence_array_ops, &array->lock,
>> +	dma_fence_init(fence, &dma_fence_array_ops, &array->lock,
>>   		       context, seqno);
>>   	init_irq_work(&array->work, irq_dma_fence_array_work);
>>   
>> @@ -174,7 +176,10 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>>   	atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
>>   	array->fences = fences;
>>   
>> -	array->base.error = PENDING_ERROR;
>> +	fence->error = PENDING_ERROR;
>> +
>> +	if (signal_on_any)
>> +		dma_fence_enable_sw_signaling(fence);
>>   
>>   	return array;
>>   }
>> diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c
>> index 1b4cb3e5cec9..0518e53880f6 100644
>> --- a/drivers/dma-buf/dma-fence-chain.c
>> +++ b/drivers/dma-buf/dma-fence-chain.c
>> @@ -152,7 +152,8 @@ static bool dma_fence_chain_enable_signaling(struct dma_fence *fence)
>>   		struct dma_fence *f = chain ? chain->fence : fence;
>>   
>>   		dma_fence_get(f);
>> -		if (!dma_fence_add_callback(f, &head->cb, dma_fence_chain_cb)) {
>> +		if (!dma_fence_add_callback_nested(f, &head->cb,
>> +						   dma_fence_chain_cb)) {
>>   			dma_fence_put(fence);
>>   			return true;
>>   		}
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 066400ed8841..90a3d5121746 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -610,6 +610,37 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence)
>>   }
>>   EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
>>   
>> +static int __dma_fence_add_callback(struct dma_fence *fence,
>> +				    struct dma_fence_cb *cb,
>> +				    dma_fence_func_t func,
>> +				    int nest_level)
>> +{
>> +	unsigned long flags;
>> +	int ret = 0;
>> +
>> +	if (WARN_ON(!fence || !func))
>> +		return -EINVAL;
>> +
>> +	if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
>> +		INIT_LIST_HEAD(&cb->node);
>> +		return -ENOENT;
>> +	}
>> +
>> +	spin_lock_irqsave_nested(fence->lock, flags, 0);
> Forgot to hook up nest_level here?

Ah Yes :)


>> +
>> +	if (__dma_fence_enable_signaling(fence)) {
>> +		cb->func = func;
>> +		list_add_tail(&cb->node, &fence->cb_list);
>> +	} else {
>> +		INIT_LIST_HEAD(&cb->node);
>> +		ret = -ENOENT;
>> +	}
>> +
>> +	spin_unlock_irqrestore(fence->lock, flags);
>> +
>> +	return ret;
>> +}
>> +
>>   /**
>>    * dma_fence_add_callback - add a callback to be called when the fence
>>    * is signaled
>> @@ -635,33 +666,33 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
>>   int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
>>   			   dma_fence_func_t func)
>>   {
>> -	unsigned long flags;
>> -	int ret = 0;
>> -
>> -	if (WARN_ON(!fence || !func))
>> -		return -EINVAL;
>> -
>> -	if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
>> -		INIT_LIST_HEAD(&cb->node);
>> -		return -ENOENT;
>> -	}
>> -
>> -	spin_lock_irqsave(fence->lock, flags);
>> -
>> -	if (__dma_fence_enable_signaling(fence)) {
>> -		cb->func = func;
>> -		list_add_tail(&cb->node, &fence->cb_list);
>> -	} else {
>> -		INIT_LIST_HEAD(&cb->node);
>> -		ret = -ENOENT;
>> -	}
>> -
>> -	spin_unlock_irqrestore(fence->lock, flags);
>> -
>> -	return ret;
>> +	return __dma_fence_add_callback(fence, cb, func, 0);
>>   }
>>   EXPORT_SYMBOL(dma_fence_add_callback);
>>   
> Other than that, I didn't investigate the nesting fails enough to say I can accurately review this. :)

Basically the problem is that within enable_signaling() which is called 
with the dma_fence lock held, we take the dma_fence lock of another 
fence. If that other fence is a dma_fence_array, or a dma_fence_chain 
which in turn tries to lock a dma_fence_array we hit a splat.

But I'll update the commit message with a typical splat.

/Thomas


>
> ~Maarten
>
>

Thomas Hellstrom Nov. 30, 2021, 12:32 p.m. UTC | #3

On 11/30/21 13:19, Thomas Hellström wrote:
> The locking order for taking two fence locks is implicitly defined in
> at least two ways in the code:
>
> 1) Fence containers first and other fences next, which is defined by
> the enable_signaling() callbacks of dma_fence_chain and
> dma_fence_array.
> 2) Reverse signal order, which is used by __i915_active_fence_set().
>
> Now 1) implies 2), except for the signal_on_any mode of dma_fence_array
> and 2) does not imply 1), and also 1) makes locking order between
> different containers confusing.
>
> Establish 2) and fix up the signal_on_any mode by calling
> enable_signaling() on such fences unlocked at creation.
>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: Christian König <[e-mail]>
> Signed-off-by: Thomas Hellström <[e-mail]>
> ---
>   drivers/dma-buf/dma-fence-array.c | 13 +++--
>   drivers/dma-buf/dma-fence-chain.c |  3 +-
>   drivers/dma-buf/dma-fence.c       | 79 +++++++++++++++++++++----------
>   include/linux/dma-fence.h         |  3 ++
>   4 files changed, 69 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c
> index 3e07f961e2f3..0322b92909fe 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -84,8 +84,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
>   		 * insufficient).
>   		 */
>   		dma_fence_get(&array->base);
> -		if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
> -					   dma_fence_array_cb_func)) {
> +		if (dma_fence_add_callback_nested(array->fences[i], &cb[i].cb,
> +						  dma_fence_array_cb_func)) {
>   			int error = array->fences[i]->error;
>   
>   			dma_fence_array_set_pending_error(array, error);
> @@ -158,6 +158,7 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>   {
>   	struct dma_fence_array *array;
>   	size_t size = sizeof(*array);
> +	struct dma_fence *fence;
>   
>   	/* Allocate the callback structures behind the array. */
>   	size += num_fences * sizeof(struct dma_fence_array_cb);
> @@ -165,8 +166,9 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>   	if (!array)
>   		return NULL;
>   
> +	fence = &array->base;
>   	spin_lock_init(&array->lock);
> -	dma_fence_init(&array->base, &dma_fence_array_ops, &array->lock,
> +	dma_fence_init(fence, &dma_fence_array_ops, &array->lock,
>   		       context, seqno);
>   	init_irq_work(&array->work, irq_dma_fence_array_work);
>   
> @@ -174,7 +176,10 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
>   	atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
>   	array->fences = fences;
>   
> -	array->base.error = PENDING_ERROR;
> +	fence->error = PENDING_ERROR;
> +
> +	if (signal_on_any)
> +		dma_fence_enable_sw_signaling(fence);

Oh, this looks strange. Was meant to call the 
dma_fence_array_enable_signaling() without the lock held here.

/Thomas

Christian König Nov. 30, 2021, 12:42 p.m. UTC | #4

Am 30.11.21 um 13:31 schrieb Thomas Hellström:
> [SNIP]
>> Other than that, I didn't investigate the nesting fails enough to say 
>> I can accurately review this. :)
>
> Basically the problem is that within enable_signaling() which is 
> called with the dma_fence lock held, we take the dma_fence lock of 
> another fence. If that other fence is a dma_fence_array, or a 
> dma_fence_chain which in turn tries to lock a dma_fence_array we hit a 
> splat.

Yeah, I already thought that you constructed something like that.

You get the splat because what you do here is illegal, you can't mix 
dma_fence_array and dma_fence_chain like this or you can end up in a 
stack corruption.

Regards,
Christian.

>
> But I'll update the commit message with a typical splat.
>
> /Thomas

Thomas Hellstrom Nov. 30, 2021, 12:56 p.m. UTC | #5

On 11/30/21 13:42, Christian König wrote:
> Am 30.11.21 um 13:31 schrieb Thomas Hellström:
>> [SNIP]
>>> Other than that, I didn't investigate the nesting fails enough to 
>>> say I can accurately review this. :)
>>
>> Basically the problem is that within enable_signaling() which is 
>> called with the dma_fence lock held, we take the dma_fence lock of 
>> another fence. If that other fence is a dma_fence_array, or a 
>> dma_fence_chain which in turn tries to lock a dma_fence_array we hit 
>> a splat.
>
> Yeah, I already thought that you constructed something like that.
>
> You get the splat because what you do here is illegal, you can't mix 
> dma_fence_array and dma_fence_chain like this or you can end up in a 
> stack corruption.

Hmm. Ok, so what is the stack corruption, is it that the 
enable_signaling() will end up with endless recursion? If so, wouldn't 
it be more usable we break that recursion chain and allow a more general 
use?

Also what are the mixing rules between these? Never use a 
dma-fence-chain as one of the array fences and never use a 
dma-fence-array as a dma-fence-chain fence?

/Thomas




>
> Regards,
> Christian.
>
>>
>> But I'll update the commit message with a typical splat.
>>
>> /Thomas
>

Christian König Nov. 30, 2021, 1:26 p.m. UTC | #6

Am 30.11.21 um 13:56 schrieb Thomas Hellström:
>
> On 11/30/21 13:42, Christian König wrote:
>> Am 30.11.21 um 13:31 schrieb Thomas Hellström:
>>> [SNIP]
>>>> Other than that, I didn't investigate the nesting fails enough to 
>>>> say I can accurately review this. :)
>>>
>>> Basically the problem is that within enable_signaling() which is 
>>> called with the dma_fence lock held, we take the dma_fence lock of 
>>> another fence. If that other fence is a dma_fence_array, or a 
>>> dma_fence_chain which in turn tries to lock a dma_fence_array we hit 
>>> a splat.
>>
>> Yeah, I already thought that you constructed something like that.
>>
>> You get the splat because what you do here is illegal, you can't mix 
>> dma_fence_array and dma_fence_chain like this or you can end up in a 
>> stack corruption.
>
> Hmm. Ok, so what is the stack corruption, is it that the 
> enable_signaling() will end up with endless recursion? If so, wouldn't 
> it be more usable we break that recursion chain and allow a more 
> general use?

The problem is that this is not easily possible for dma_fence_array 
containers. Just imagine that you drop the last reference to the 
containing fences during dma_fence_array destruction if any of the 
contained fences is another container you can easily run into recursion 
and with that stack corruption.

That's one of the major reasons I came up with the dma_fence_chain 
container. This one you can chain any number of elements together 
without running into any recursion.

> Also what are the mixing rules between these? Never use a 
> dma-fence-chain as one of the array fences and never use a 
> dma-fence-array as a dma-fence-chain fence?

You can't add any other container to a dma_fence_array, neither other 
dma_fence_array instances nor dma_fence_chain instances.

IIRC at least technically a dma_fence_chain can contain a 
dma_fence_array if you absolutely need that, but Daniel, Jason and I 
already had the same discussion a while back and came to the conclusion 
to avoid that as well if possible.

Regards,
Christian.

>
> /Thomas
>
>
>
>
>>
>> Regards,
>> Christian.
>>
>>>
>>> But I'll update the commit message with a typical splat.
>>>
>>> /Thomas
>>

Thomas Hellstrom Nov. 30, 2021, 2:35 p.m. UTC | #7

On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:
> Am 30.11.21 um 13:56 schrieb Thomas Hellström:
> > 
> > On 11/30/21 13:42, Christian König wrote:
> > > Am 30.11.21 um 13:31 schrieb Thomas Hellström:
> > > > [SNIP]
> > > > > Other than that, I didn't investigate the nesting fails
> > > > > enough to 
> > > > > say I can accurately review this. :)
> > > > 
> > > > Basically the problem is that within enable_signaling() which
> > > > is 
> > > > called with the dma_fence lock held, we take the dma_fence lock
> > > > of 
> > > > another fence. If that other fence is a dma_fence_array, or a 
> > > > dma_fence_chain which in turn tries to lock a dma_fence_array
> > > > we hit 
> > > > a splat.
> > > 
> > > Yeah, I already thought that you constructed something like that.
> > > 
> > > You get the splat because what you do here is illegal, you can't
> > > mix 
> > > dma_fence_array and dma_fence_chain like this or you can end up
> > > in a 
> > > stack corruption.
> > 
> > Hmm. Ok, so what is the stack corruption, is it that the 
> > enable_signaling() will end up with endless recursion? If so,
> > wouldn't 
> > it be more usable we break that recursion chain and allow a more 
> > general use?
> 
> The problem is that this is not easily possible for dma_fence_array 
> containers. Just imagine that you drop the last reference to the 
> containing fences during dma_fence_array destruction if any of the 
> contained fences is another container you can easily run into
> recursion 
> and with that stack corruption.

Indeed, that would require some deeper surgery.

> 
> That's one of the major reasons I came up with the dma_fence_chain 
> container. This one you can chain any number of elements together 
> without running into any recursion.
> 
> > Also what are the mixing rules between these? Never use a 
> > dma-fence-chain as one of the array fences and never use a 
> > dma-fence-array as a dma-fence-chain fence?
> 
> You can't add any other container to a dma_fence_array, neither other
> dma_fence_array instances nor dma_fence_chain instances.
> 
> IIRC at least technically a dma_fence_chain can contain a 
> dma_fence_array if you absolutely need that, but Daniel, Jason and I 
> already had the same discussion a while back and came to the
> conclusion 
> to avoid that as well if possible.

Yes, this is actually the use-case. But what I can't easily guarantee
is that that dma_fence_chain isn't fed into a dma_fence_array somewhere
else. How do you typically avoid that?

Meanwhile I guess I need to take a different approach in the driver to
avoid this altogether.

/Thomas


> 
> Regards,
> Christian.
> 
> > 
> > /Thomas
> > 
> > 
> > 
> > 
> > > 
> > > Regards,
> > > Christian.
> > > 
> > > > 
> > > > But I'll update the commit message with a typical splat.
> > > > 
> > > > /Thomas
> > > 
>

Christian König Nov. 30, 2021, 3:02 p.m. UTC | #8

Am 30.11.21 um 15:35 schrieb Thomas Hellström:
> On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:
>> Am 30.11.21 um 13:56 schrieb Thomas Hellström:
>>> On 11/30/21 13:42, Christian König wrote:
>>>> Am 30.11.21 um 13:31 schrieb Thomas Hellström:
>>>>> [SNIP]
>>>>>> Other than that, I didn't investigate the nesting fails
>>>>>> enough to
>>>>>> say I can accurately review this. :)
>>>>> Basically the problem is that within enable_signaling() which
>>>>> is
>>>>> called with the dma_fence lock held, we take the dma_fence lock
>>>>> of
>>>>> another fence. If that other fence is a dma_fence_array, or a
>>>>> dma_fence_chain which in turn tries to lock a dma_fence_array
>>>>> we hit
>>>>> a splat.
>>>> Yeah, I already thought that you constructed something like that.
>>>>
>>>> You get the splat because what you do here is illegal, you can't
>>>> mix
>>>> dma_fence_array and dma_fence_chain like this or you can end up
>>>> in a
>>>> stack corruption.
>>> Hmm. Ok, so what is the stack corruption, is it that the
>>> enable_signaling() will end up with endless recursion? If so,
>>> wouldn't
>>> it be more usable we break that recursion chain and allow a more
>>> general use?
>> The problem is that this is not easily possible for dma_fence_array
>> containers. Just imagine that you drop the last reference to the
>> containing fences during dma_fence_array destruction if any of the
>> contained fences is another container you can easily run into
>> recursion
>> and with that stack corruption.
> Indeed, that would require some deeper surgery.
>
>> That's one of the major reasons I came up with the dma_fence_chain
>> container. This one you can chain any number of elements together
>> without running into any recursion.
>>
>>> Also what are the mixing rules between these? Never use a
>>> dma-fence-chain as one of the array fences and never use a
>>> dma-fence-array as a dma-fence-chain fence?
>> You can't add any other container to a dma_fence_array, neither other
>> dma_fence_array instances nor dma_fence_chain instances.
>>
>> IIRC at least technically a dma_fence_chain can contain a
>> dma_fence_array if you absolutely need that, but Daniel, Jason and I
>> already had the same discussion a while back and came to the
>> conclusion
>> to avoid that as well if possible.
> Yes, this is actually the use-case. But what I can't easily guarantee
> is that that dma_fence_chain isn't fed into a dma_fence_array somewhere
> else. How do you typically avoid that?
>
> Meanwhile I guess I need to take a different approach in the driver to
> avoid this altogether.

Jason and I came up with a deep dive iterator for his use case, but I 
think we don't want to use that any more after my dma_resv rework.

In other words when you need to create a new dma_fence_array you flatten 
out the existing construct which is at worst case 
dma_fence_chain->dma_fence_array->dma_fence.

Regards,
Christian.

>
> /Thomas
>
>
>> Regards,
>> Christian.
>>
>>> /Thomas
>>>
>>>
>>>
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> But I'll update the commit message with a typical splat.
>>>>>
>>>>> /Thomas
>

Thomas Hellstrom Nov. 30, 2021, 6:12 p.m. UTC | #9

On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote:
> Am 30.11.21 um 15:35 schrieb Thomas Hellström:
> > On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:
> > > Am 30.11.21 um 13:56 schrieb Thomas Hellström:
> > > > On 11/30/21 13:42, Christian König wrote:
> > > > > Am 30.11.21 um 13:31 schrieb Thomas Hellström:
> > > > > > [SNIP]
> > > > > > > Other than that, I didn't investigate the nesting fails
> > > > > > > enough to
> > > > > > > say I can accurately review this. :)
> > > > > > Basically the problem is that within enable_signaling()
> > > > > > which
> > > > > > is
> > > > > > called with the dma_fence lock held, we take the dma_fence
> > > > > > lock
> > > > > > of
> > > > > > another fence. If that other fence is a dma_fence_array, or
> > > > > > a
> > > > > > dma_fence_chain which in turn tries to lock a
> > > > > > dma_fence_array
> > > > > > we hit
> > > > > > a splat.
> > > > > Yeah, I already thought that you constructed something like
> > > > > that.
> > > > > 
> > > > > You get the splat because what you do here is illegal, you
> > > > > can't
> > > > > mix
> > > > > dma_fence_array and dma_fence_chain like this or you can end
> > > > > up
> > > > > in a
> > > > > stack corruption.
> > > > Hmm. Ok, so what is the stack corruption, is it that the
> > > > enable_signaling() will end up with endless recursion? If so,
> > > > wouldn't
> > > > it be more usable we break that recursion chain and allow a
> > > > more
> > > > general use?
> > > The problem is that this is not easily possible for
> > > dma_fence_array
> > > containers. Just imagine that you drop the last reference to the
> > > containing fences during dma_fence_array destruction if any of
> > > the
> > > contained fences is another container you can easily run into
> > > recursion
> > > and with that stack corruption.
> > Indeed, that would require some deeper surgery.
> > 
> > > That's one of the major reasons I came up with the
> > > dma_fence_chain
> > > container. This one you can chain any number of elements together
> > > without running into any recursion.
> > > 
> > > > Also what are the mixing rules between these? Never use a
> > > > dma-fence-chain as one of the array fences and never use a
> > > > dma-fence-array as a dma-fence-chain fence?
> > > You can't add any other container to a dma_fence_array, neither
> > > other
> > > dma_fence_array instances nor dma_fence_chain instances.
> > > 
> > > IIRC at least technically a dma_fence_chain can contain a
> > > dma_fence_array if you absolutely need that, but Daniel, Jason
> > > and I
> > > already had the same discussion a while back and came to the
> > > conclusion
> > > to avoid that as well if possible.
> > Yes, this is actually the use-case. But what I can't easily
> > guarantee
> > is that that dma_fence_chain isn't fed into a dma_fence_array
> > somewhere
> > else. How do you typically avoid that?
> > 
> > Meanwhile I guess I need to take a different approach in the driver
> > to
> > avoid this altogether.
> 
> Jason and I came up with a deep dive iterator for his use case, but I
> think we don't want to use that any more after my dma_resv rework.
> 
> In other words when you need to create a new dma_fence_array you
> flatten 
> out the existing construct which is at worst case 
> dma_fence_chain->dma_fence_array->dma_fence.

Ok, Are there any cross-driver contract here, Like every driver using a
dma_fence_array need to check for dma_fence_chain and flatten like
above?

/Thomas


> 
> Regards,
> Christian.
> 
> > 
> > /Thomas
> > 
> > 
> > > Regards,
> > > Christian.
> > > 
> > > > /Thomas
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > Regards,
> > > > > Christian.
> > > > > 
> > > > > > But I'll update the commit message with a typical splat.
> > > > > > 
> > > > > > /Thomas
> > 
>

Thomas Hellstrom Nov. 30, 2021, 7:27 p.m. UTC | #10

On 11/30/21 19:12, Thomas Hellström wrote:
> On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote:
>> Am 30.11.21 um 15:35 schrieb Thomas Hellström:
>>> On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:
>>>> Am 30.11.21 um 13:56 schrieb Thomas Hellström:
>>>>> On 11/30/21 13:42, Christian König wrote:
>>>>>> Am 30.11.21 um 13:31 schrieb Thomas Hellström:
>>>>>>> [SNIP]
>>>>>>>> Other than that, I didn't investigate the nesting fails
>>>>>>>> enough to
>>>>>>>> say I can accurately review this. :)
>>>>>>> Basically the problem is that within enable_signaling()
>>>>>>> which
>>>>>>> is
>>>>>>> called with the dma_fence lock held, we take the dma_fence
>>>>>>> lock
>>>>>>> of
>>>>>>> another fence. If that other fence is a dma_fence_array, or
>>>>>>> a
>>>>>>> dma_fence_chain which in turn tries to lock a
>>>>>>> dma_fence_array
>>>>>>> we hit
>>>>>>> a splat.
>>>>>> Yeah, I already thought that you constructed something like
>>>>>> that.
>>>>>>
>>>>>> You get the splat because what you do here is illegal, you
>>>>>> can't
>>>>>> mix
>>>>>> dma_fence_array and dma_fence_chain like this or you can end
>>>>>> up
>>>>>> in a
>>>>>> stack corruption.
>>>>> Hmm. Ok, so what is the stack corruption, is it that the
>>>>> enable_signaling() will end up with endless recursion? If so,
>>>>> wouldn't
>>>>> it be more usable we break that recursion chain and allow a
>>>>> more
>>>>> general use?
>>>> The problem is that this is not easily possible for
>>>> dma_fence_array
>>>> containers. Just imagine that you drop the last reference to the
>>>> containing fences during dma_fence_array destruction if any of
>>>> the
>>>> contained fences is another container you can easily run into
>>>> recursion
>>>> and with that stack corruption.
>>> Indeed, that would require some deeper surgery.
>>>
>>>> That's one of the major reasons I came up with the
>>>> dma_fence_chain
>>>> container. This one you can chain any number of elements together
>>>> without running into any recursion.
>>>>
>>>>> Also what are the mixing rules between these? Never use a
>>>>> dma-fence-chain as one of the array fences and never use a
>>>>> dma-fence-array as a dma-fence-chain fence?
>>>> You can't add any other container to a dma_fence_array, neither
>>>> other
>>>> dma_fence_array instances nor dma_fence_chain instances.
>>>>
>>>> IIRC at least technically a dma_fence_chain can contain a
>>>> dma_fence_array if you absolutely need that, but Daniel, Jason
>>>> and I
>>>> already had the same discussion a while back and came to the
>>>> conclusion
>>>> to avoid that as well if possible.
>>> Yes, this is actually the use-case. But what I can't easily
>>> guarantee
>>> is that that dma_fence_chain isn't fed into a dma_fence_array
>>> somewhere
>>> else. How do you typically avoid that?
>>>
>>> Meanwhile I guess I need to take a different approach in the driver
>>> to
>>> avoid this altogether.
>> Jason and I came up with a deep dive iterator for his use case, but I
>> think we don't want to use that any more after my dma_resv rework.
>>
>> In other words when you need to create a new dma_fence_array you
>> flatten
>> out the existing construct which is at worst case
>> dma_fence_chain->dma_fence_array->dma_fence.
> Ok, Are there any cross-driver contract here, Like every driver using a
> dma_fence_array need to check for dma_fence_chain and flatten like
> above?
>
> /Thomas

Oh, and a follow up question:

If there was a way to break the recursion on final put() (using the same 
basic approach as patch 2 in this series uses to break recursion in 
enable_signaling()), so that none of these containers did require any 
special treatment, would it be worth pursuing? I guess it might be 
possible by having the callbacks drop the references rather than the 
loop in the final put. + a couple of changes in code iterating over the 
fence pointers.

/Thomas

>
>> Regards,
>> Christian.
>>
>>> /Thomas
>>>
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> /Thomas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regards,
>>>>>> Christian.
>>>>>>
>>>>>>> But I'll update the commit message with a typical splat.
>>>>>>>
>>>>>>> /Thomas

Christian König Dec. 1, 2021, 7:05 a.m. UTC | #11

Am 30.11.21 um 20:27 schrieb Thomas Hellström:
>
> On 11/30/21 19:12, Thomas Hellström wrote:
>> On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote:
>>> Am 30.11.21 um 15:35 schrieb Thomas Hellström:
>>>> On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:
>>>>> Am 30.11.21 um 13:56 schrieb Thomas Hellström:
>>>>>> On 11/30/21 13:42, Christian König wrote:
>>>>>>> Am 30.11.21 um 13:31 schrieb Thomas Hellström:
>>>>>>>> [SNIP]
>>>>>>>>> Other than that, I didn't investigate the nesting fails
>>>>>>>>> enough to
>>>>>>>>> say I can accurately review this. :)
>>>>>>>> Basically the problem is that within enable_signaling()
>>>>>>>> which
>>>>>>>> is
>>>>>>>> called with the dma_fence lock held, we take the dma_fence
>>>>>>>> lock
>>>>>>>> of
>>>>>>>> another fence. If that other fence is a dma_fence_array, or
>>>>>>>> a
>>>>>>>> dma_fence_chain which in turn tries to lock a
>>>>>>>> dma_fence_array
>>>>>>>> we hit
>>>>>>>> a splat.
>>>>>>> Yeah, I already thought that you constructed something like
>>>>>>> that.
>>>>>>>
>>>>>>> You get the splat because what you do here is illegal, you
>>>>>>> can't
>>>>>>> mix
>>>>>>> dma_fence_array and dma_fence_chain like this or you can end
>>>>>>> up
>>>>>>> in a
>>>>>>> stack corruption.
>>>>>> Hmm. Ok, so what is the stack corruption, is it that the
>>>>>> enable_signaling() will end up with endless recursion? If so,
>>>>>> wouldn't
>>>>>> it be more usable we break that recursion chain and allow a
>>>>>> more
>>>>>> general use?
>>>>> The problem is that this is not easily possible for
>>>>> dma_fence_array
>>>>> containers. Just imagine that you drop the last reference to the
>>>>> containing fences during dma_fence_array destruction if any of
>>>>> the
>>>>> contained fences is another container you can easily run into
>>>>> recursion
>>>>> and with that stack corruption.
>>>> Indeed, that would require some deeper surgery.
>>>>
>>>>> That's one of the major reasons I came up with the
>>>>> dma_fence_chain
>>>>> container. This one you can chain any number of elements together
>>>>> without running into any recursion.
>>>>>
>>>>>> Also what are the mixing rules between these? Never use a
>>>>>> dma-fence-chain as one of the array fences and never use a
>>>>>> dma-fence-array as a dma-fence-chain fence?
>>>>> You can't add any other container to a dma_fence_array, neither
>>>>> other
>>>>> dma_fence_array instances nor dma_fence_chain instances.
>>>>>
>>>>> IIRC at least technically a dma_fence_chain can contain a
>>>>> dma_fence_array if you absolutely need that, but Daniel, Jason
>>>>> and I
>>>>> already had the same discussion a while back and came to the
>>>>> conclusion
>>>>> to avoid that as well if possible.
>>>> Yes, this is actually the use-case. But what I can't easily
>>>> guarantee
>>>> is that that dma_fence_chain isn't fed into a dma_fence_array
>>>> somewhere
>>>> else. How do you typically avoid that?
>>>>
>>>> Meanwhile I guess I need to take a different approach in the driver
>>>> to
>>>> avoid this altogether.
>>> Jason and I came up with a deep dive iterator for his use case, but I
>>> think we don't want to use that any more after my dma_resv rework.
>>>
>>> In other words when you need to create a new dma_fence_array you
>>> flatten
>>> out the existing construct which is at worst case
>>> dma_fence_chain->dma_fence_array->dma_fence.
>> Ok, Are there any cross-driver contract here, Like every driver using a
>> dma_fence_array need to check for dma_fence_chain and flatten like
>> above?

So far we only discussed that on the mailing list but haven't made any 
documentation for that.

>>
>> /Thomas
>
> Oh, and a follow up question:
>
> If there was a way to break the recursion on final put() (using the 
> same basic approach as patch 2 in this series uses to break recursion 
> in enable_signaling()), so that none of these containers did require 
> any special treatment, would it be worth pursuing? I guess it might be 
> possible by having the callbacks drop the references rather than the 
> loop in the final put. + a couple of changes in code iterating over 
> the fence pointers.

That won't really help, you just move the recursion from the final put 
into the callback.

What could be possible is to use an work item for any possible 
operation, e.g. enabling, signaling and destruction. But in the last 
discussion everybody agreed that it is better to just flatten out the array.

Christian.

>
>
> /Thomas
>
>>
>>> Regards,
>>> Christian.
>>>
>>>> /Thomas
>>>>
>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>> /Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Christian.
>>>>>>>
>>>>>>>> But I'll update the commit message with a typical splat.
>>>>>>>>
>>>>>>>> /Thomas

Thomas Hellström (Intel) Dec. 1, 2021, 8:23 a.m. UTC | #12

On 12/1/21 08:05, Christian König wrote:
> Am 30.11.21 um 20:27 schrieb Thomas Hellström:
>>
>> On 11/30/21 19:12, Thomas Hellström wrote:
>>> On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote:
>>>> Am 30.11.21 um 15:35 schrieb Thomas Hellström:
>>>>> On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:
>>>>>> Am 30.11.21 um 13:56 schrieb Thomas Hellström:
>>>>>>> On 11/30/21 13:42, Christian König wrote:
>>>>>>>> Am 30.11.21 um 13:31 schrieb Thomas Hellström:
>>>>>>>>> [SNIP]
>>>>>>>>>> Other than that, I didn't investigate the nesting fails
>>>>>>>>>> enough to
>>>>>>>>>> say I can accurately review this. :)
>>>>>>>>> Basically the problem is that within enable_signaling()
>>>>>>>>> which
>>>>>>>>> is
>>>>>>>>> called with the dma_fence lock held, we take the dma_fence
>>>>>>>>> lock
>>>>>>>>> of
>>>>>>>>> another fence. If that other fence is a dma_fence_array, or
>>>>>>>>> a
>>>>>>>>> dma_fence_chain which in turn tries to lock a
>>>>>>>>> dma_fence_array
>>>>>>>>> we hit
>>>>>>>>> a splat.
>>>>>>>> Yeah, I already thought that you constructed something like
>>>>>>>> that.
>>>>>>>>
>>>>>>>> You get the splat because what you do here is illegal, you
>>>>>>>> can't
>>>>>>>> mix
>>>>>>>> dma_fence_array and dma_fence_chain like this or you can end
>>>>>>>> up
>>>>>>>> in a
>>>>>>>> stack corruption.
>>>>>>> Hmm. Ok, so what is the stack corruption, is it that the
>>>>>>> enable_signaling() will end up with endless recursion? If so,
>>>>>>> wouldn't
>>>>>>> it be more usable we break that recursion chain and allow a
>>>>>>> more
>>>>>>> general use?
>>>>>> The problem is that this is not easily possible for
>>>>>> dma_fence_array
>>>>>> containers. Just imagine that you drop the last reference to the
>>>>>> containing fences during dma_fence_array destruction if any of
>>>>>> the
>>>>>> contained fences is another container you can easily run into
>>>>>> recursion
>>>>>> and with that stack corruption.
>>>>> Indeed, that would require some deeper surgery.
>>>>>
>>>>>> That's one of the major reasons I came up with the
>>>>>> dma_fence_chain
>>>>>> container. This one you can chain any number of elements together
>>>>>> without running into any recursion.
>>>>>>
>>>>>>> Also what are the mixing rules between these? Never use a
>>>>>>> dma-fence-chain as one of the array fences and never use a
>>>>>>> dma-fence-array as a dma-fence-chain fence?
>>>>>> You can't add any other container to a dma_fence_array, neither
>>>>>> other
>>>>>> dma_fence_array instances nor dma_fence_chain instances.
>>>>>>
>>>>>> IIRC at least technically a dma_fence_chain can contain a
>>>>>> dma_fence_array if you absolutely need that, but Daniel, Jason
>>>>>> and I
>>>>>> already had the same discussion a while back and came to the
>>>>>> conclusion
>>>>>> to avoid that as well if possible.
>>>>> Yes, this is actually the use-case. But what I can't easily
>>>>> guarantee
>>>>> is that that dma_fence_chain isn't fed into a dma_fence_array
>>>>> somewhere
>>>>> else. How do you typically avoid that?
>>>>>
>>>>> Meanwhile I guess I need to take a different approach in the driver
>>>>> to
>>>>> avoid this altogether.
>>>> Jason and I came up with a deep dive iterator for his use case, but I
>>>> think we don't want to use that any more after my dma_resv rework.
>>>>
>>>> In other words when you need to create a new dma_fence_array you
>>>> flatten
>>>> out the existing construct which is at worst case
>>>> dma_fence_chain->dma_fence_array->dma_fence.
>>> Ok, Are there any cross-driver contract here, Like every driver using a
>>> dma_fence_array need to check for dma_fence_chain and flatten like
>>> above?
>
> So far we only discussed that on the mailing list but haven't made any 
> documentation for that.

OK, one other cross-driver pitfall I see is if someone accidently joins 
two fence chains together by creating a fence chain unknowingly using 
another fence chain as the @fence argument?

The third cross-driver pitfall IMHO is the locking dependency these 
containers add. Other drivers (read at least i915) may have defined 
slightly different locking orders and that should also be addressed if 
needed, but that requires a cross driver agreement what the locking 
orders really are. Patch 1 actually addresses this, while keeping the 
container lockdep warnings for deep recursions, so at least I think that 
could serve as a discussion starter.

>
>
>>>
>>> /Thomas
>>
>> Oh, and a follow up question:
>>
>> If there was a way to break the recursion on final put() (using the 
>> same basic approach as patch 2 in this series uses to break recursion 
>> in enable_signaling()), so that none of these containers did require 
>> any special treatment, would it be worth pursuing? I guess it might 
>> be possible by having the callbacks drop the references rather than 
>> the loop in the final put. + a couple of changes in code iterating 
>> over the fence pointers.
>
> That won't really help, you just move the recursion from the final put 
> into the callback.

How do we recurse from the callback? The introduced fence_put() of 
individual fence pointers
doesn't recurse anymore (at most 1 level), and any callback recursion is 
broken by the irq_work?

I figure the big amount of work would be to adjust code that iterates 
over the individual fence pointers to recognize that they are rcu protected.

Thanks,

/Thomas

Christian König Dec. 1, 2021, 8:36 a.m. UTC | #13

Am 01.12.21 um 09:23 schrieb Thomas Hellström (Intel):
>  [SNIP]
>>>>> Jason and I came up with a deep dive iterator for his use case, but I
>>>>> think we don't want to use that any more after my dma_resv rework.
>>>>>
>>>>> In other words when you need to create a new dma_fence_array you
>>>>> flatten
>>>>> out the existing construct which is at worst case
>>>>> dma_fence_chain->dma_fence_array->dma_fence.
>>>> Ok, Are there any cross-driver contract here, Like every driver 
>>>> using a
>>>> dma_fence_array need to check for dma_fence_chain and flatten like
>>>> above?
>>
>> So far we only discussed that on the mailing list but haven't made 
>> any documentation for that.
>
> OK, one other cross-driver pitfall I see is if someone accidently 
> joins two fence chains together by creating a fence chain unknowingly 
> using another fence chain as the @fence argument?

That would indeed be illegal and we should probably add a WARN_ON() for 
that.

>
> The third cross-driver pitfall IMHO is the locking dependency these 
> containers add. Other drivers (read at least i915) may have defined 
> slightly different locking orders and that should also be addressed if 
> needed, but that requires a cross driver agreement what the locking 
> orders really are. Patch 1 actually addresses this, while keeping the 
> container lockdep warnings for deep recursions, so at least I think 
> that could serve as a discussion starter.

No, drivers should never make any assumptions on that.

E.g. when you need to take a look from a callback you must guarantee 
that you never have that lock taken when you call any of the dma_fence 
functions. Your patch breaks the lockdep annotation for that.

What we could do is to avoid all this by not calling the callback with 
the lock held in the first place.

>>
>>>>
>>>> /Thomas
>>>
>>> Oh, and a follow up question:
>>>
>>> If there was a way to break the recursion on final put() (using the 
>>> same basic approach as patch 2 in this series uses to break 
>>> recursion in enable_signaling()), so that none of these containers 
>>> did require any special treatment, would it be worth pursuing? I 
>>> guess it might be possible by having the callbacks drop the 
>>> references rather than the loop in the final put. + a couple of 
>>> changes in code iterating over the fence pointers.
>>
>> That won't really help, you just move the recursion from the final 
>> put into the callback.
>
> How do we recurse from the callback? The introduced fence_put() of 
> individual fence pointers
> doesn't recurse anymore (at most 1 level), and any callback recursion 
> is broken by the irq_work?

Yeah, but then you would need to take another lock to avoid racing with 
dma_fence_array_signaled().

>
> I figure the big amount of work would be to adjust code that iterates 
> over the individual fence pointers to recognize that they are rcu 
> protected.

Could be that we could solve this with RCU, but that sounds like a lot 
of churn for no gain at all.

In other words even with the problems solved I think it would be a 
really bad idea to allow chaining of dma_fence_array objects.

Christian.

>
>
> Thanks,
>
> /Thomas
>
>

Thomas Hellström (Intel) Dec. 1, 2021, 10:15 a.m. UTC | #14

On 12/1/21 09:36, Christian König wrote:
> Am 01.12.21 um 09:23 schrieb Thomas Hellström (Intel):
>>  [SNIP]
>>>>>> Jason and I came up with a deep dive iterator for his use case, 
>>>>>> but I
>>>>>> think we don't want to use that any more after my dma_resv rework.
>>>>>>
>>>>>> In other words when you need to create a new dma_fence_array you
>>>>>> flatten
>>>>>> out the existing construct which is at worst case
>>>>>> dma_fence_chain->dma_fence_array->dma_fence.
>>>>> Ok, Are there any cross-driver contract here, Like every driver 
>>>>> using a
>>>>> dma_fence_array need to check for dma_fence_chain and flatten like
>>>>> above?
>>>
>>> So far we only discussed that on the mailing list but haven't made 
>>> any documentation for that.
>>
>> OK, one other cross-driver pitfall I see is if someone accidently 
>> joins two fence chains together by creating a fence chain unknowingly 
>> using another fence chain as the @fence argument?
>
> That would indeed be illegal and we should probably add a WARN_ON() 
> for that.
>
>>
>> The third cross-driver pitfall IMHO is the locking dependency these 
>> containers add. Other drivers (read at least i915) may have defined 
>> slightly different locking orders and that should also be addressed 
>> if needed, but that requires a cross driver agreement what the 
>> locking orders really are. Patch 1 actually addresses this, while 
>> keeping the container lockdep warnings for deep recursions, so at 
>> least I think that could serve as a discussion starter.
>
> No, drivers should never make any assumptions on that.

Yes that i915 assumption of taking the lock of the last signaled fence 
first goes back a while in time. We should look at fixing that up, and 
document any (possibly forbidden) assumptions about fence lock locking 
orders to avoid it happening again, if there is no common cross-driver 
locking order that can be agreed.

>
> E.g. when you need to take a look from a callback you must guarantee 
> that you never have that lock taken when you call any of the dma_fence 
> functions. Your patch breaks the lockdep annotation for that.

I'm pretty sure that could be fixed in a satisfactory way if needed.

>
> What we could do is to avoid all this by not calling the callback with 
> the lock held in the first place.

If that's possible that might be a good idea, pls also see below.

>
>>>
>>>>>
>>>>> /Thomas
>>>>
>>>> Oh, and a follow up question:
>>>>
>>>> If there was a way to break the recursion on final put() (using the 
>>>> same basic approach as patch 2 in this series uses to break 
>>>> recursion in enable_signaling()), so that none of these containers 
>>>> did require any special treatment, would it be worth pursuing? I 
>>>> guess it might be possible by having the callbacks drop the 
>>>> references rather than the loop in the final put. + a couple of 
>>>> changes in code iterating over the fence pointers.
>>>
>>> That won't really help, you just move the recursion from the final 
>>> put into the callback.
>>
>> How do we recurse from the callback? The introduced fence_put() of 
>> individual fence pointers
>> doesn't recurse anymore (at most 1 level), and any callback recursion 
>> is broken by the irq_work?
>
> Yeah, but then you would need to take another lock to avoid racing 
> with dma_fence_array_signaled().
>
>>
>> I figure the big amount of work would be to adjust code that iterates 
>> over the individual fence pointers to recognize that they are rcu 
>> protected.
>
> Could be that we could solve this with RCU, but that sounds like a lot 
> of churn for no gain at all.
>
> In other words even with the problems solved I think it would be a 
> really bad idea to allow chaining of dma_fence_array objects.

Yes, that was really the question, Is it worth pursuing this? I'm not 
really suggesting we should allow this as an intentional feature. I'm 
worried, however, that if we allow these containers to start floating 
around cross-driver (or even internally) disguised as ordinary 
dma_fences, they would require a lot of driver special casing, or else 
completely unexpeced WARN_ON()s and lockdep splats would start to turn 
up, scaring people off from using them. And that would be a breeding 
ground for hairy driver-private constructs.

/Thomas


>
> Christian.
>
>>
>>
>> Thanks,
>>
>> /Thomas
>>
>>

Christian König Dec. 1, 2021, 10:32 a.m. UTC | #15

Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
> [SNIP]
>>
>> What we could do is to avoid all this by not calling the callback 
>> with the lock held in the first place.
>
> If that's possible that might be a good idea, pls also see below.

The problem with that is 
dma_fence_signal_locked()/dma_fence_signal_timestamp_locked(). If we 
could avoid using that or at least allow it to drop the lock then we 
could call the callback without holding it.

Somebody would need to audit the drivers and see if holding the lock is 
really necessary anywhere.

>>
>>>>
>>>>>>
>>>>>> /Thomas
>>>>>
>>>>> Oh, and a follow up question:
>>>>>
>>>>> If there was a way to break the recursion on final put() (using 
>>>>> the same basic approach as patch 2 in this series uses to break 
>>>>> recursion in enable_signaling()), so that none of these containers 
>>>>> did require any special treatment, would it be worth pursuing? I 
>>>>> guess it might be possible by having the callbacks drop the 
>>>>> references rather than the loop in the final put. + a couple of 
>>>>> changes in code iterating over the fence pointers.
>>>>
>>>> That won't really help, you just move the recursion from the final 
>>>> put into the callback.
>>>
>>> How do we recurse from the callback? The introduced fence_put() of 
>>> individual fence pointers
>>> doesn't recurse anymore (at most 1 level), and any callback 
>>> recursion is broken by the irq_work?
>>
>> Yeah, but then you would need to take another lock to avoid racing 
>> with dma_fence_array_signaled().
>>
>>>
>>> I figure the big amount of work would be to adjust code that 
>>> iterates over the individual fence pointers to recognize that they 
>>> are rcu protected.
>>
>> Could be that we could solve this with RCU, but that sounds like a 
>> lot of churn for no gain at all.
>>
>> In other words even with the problems solved I think it would be a 
>> really bad idea to allow chaining of dma_fence_array objects.
>
> Yes, that was really the question, Is it worth pursuing this? I'm not 
> really suggesting we should allow this as an intentional feature. I'm 
> worried, however, that if we allow these containers to start floating 
> around cross-driver (or even internally) disguised as ordinary 
> dma_fences, they would require a lot of driver special casing, or else 
> completely unexpeced WARN_ON()s and lockdep splats would start to turn 
> up, scaring people off from using them. And that would be a breeding 
> ground for hairy driver-private constructs.

Well the question is why we would want to do it?

If it's to avoid inter driver lock dependencies by avoiding to call the 
callback with the spinlock held, then yes please. We had tons of 
problems with that, resulting in irq_work and work_item delegation all 
over the place.

If it's to allow nesting of dma_fence_array instances, then it's most 
likely a really bad idea even if we fix all the locking order problems.

Christian.

>
> /Thomas
>
>
>>
>> Christian.
>>
>>>
>>>
>>> Thanks,
>>>
>>> /Thomas
>>>
>>>

Thomas Hellström (Intel) Dec. 1, 2021, 11:04 a.m. UTC | #16

On 12/1/21 11:32, Christian König wrote:
> Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
>> [SNIP]
>>>
>>> What we could do is to avoid all this by not calling the callback 
>>> with the lock held in the first place.
>>
>> If that's possible that might be a good idea, pls also see below.
>
> The problem with that is 
> dma_fence_signal_locked()/dma_fence_signal_timestamp_locked(). If we 
> could avoid using that or at least allow it to drop the lock then we 
> could call the callback without holding it.
>
> Somebody would need to audit the drivers and see if holding the lock 
> is really necessary anywhere.
>
>>>
>>>>>
>>>>>>>
>>>>>>> /Thomas
>>>>>>
>>>>>> Oh, and a follow up question:
>>>>>>
>>>>>> If there was a way to break the recursion on final put() (using 
>>>>>> the same basic approach as patch 2 in this series uses to break 
>>>>>> recursion in enable_signaling()), so that none of these 
>>>>>> containers did require any special treatment, would it be worth 
>>>>>> pursuing? I guess it might be possible by having the callbacks 
>>>>>> drop the references rather than the loop in the final put. + a 
>>>>>> couple of changes in code iterating over the fence pointers.
>>>>>
>>>>> That won't really help, you just move the recursion from the final 
>>>>> put into the callback.
>>>>
>>>> How do we recurse from the callback? The introduced fence_put() of 
>>>> individual fence pointers
>>>> doesn't recurse anymore (at most 1 level), and any callback 
>>>> recursion is broken by the irq_work?
>>>
>>> Yeah, but then you would need to take another lock to avoid racing 
>>> with dma_fence_array_signaled().
>>>
>>>>
>>>> I figure the big amount of work would be to adjust code that 
>>>> iterates over the individual fence pointers to recognize that they 
>>>> are rcu protected.
>>>
>>> Could be that we could solve this with RCU, but that sounds like a 
>>> lot of churn for no gain at all.
>>>
>>> In other words even with the problems solved I think it would be a 
>>> really bad idea to allow chaining of dma_fence_array objects.
>>
>> Yes, that was really the question, Is it worth pursuing this? I'm not 
>> really suggesting we should allow this as an intentional feature. I'm 
>> worried, however, that if we allow these containers to start floating 
>> around cross-driver (or even internally) disguised as ordinary 
>> dma_fences, they would require a lot of driver special casing, or 
>> else completely unexpeced WARN_ON()s and lockdep splats would start 
>> to turn up, scaring people off from using them. And that would be a 
>> breeding ground for hairy driver-private constructs.
>
> Well the question is why we would want to do it?
>
> If it's to avoid inter driver lock dependencies by avoiding to call 
> the callback with the spinlock held, then yes please. We had tons of 
> problems with that, resulting in irq_work and work_item delegation all 
> over the place.

Yes, that sounds like something desirable, but in these containers, 
what's causing the lock dependencies is the enable_signaling() callback 
that is typically called locked.


>
> If it's to allow nesting of dma_fence_array instances, then it's most 
> likely a really bad idea even if we fix all the locking order problems.

Well I think my use-case where I hit a dead end may illustrate what 
worries me here:

1) We use a dma-fence-array to coalesce all dependencies for ttm object 
migration.
2) We use a dma-fence-chain to order the resulting dm_fence into a 
timeline because the TTM resource manager code requires that.

Initially seemingly harmless to me.

But after a sequence evict->alloc->clear, the dma-fence-chain feeds into 
the dma-fence-array for the clearing operation. Code still works fine, 
and no deep recursion, no warnings. But if I were to add another driver 
to the system that instead feeds a dma-fence-array into a 
dma-fence-chain, this would give me a lockdep splat.

So then if somebody were to come up with the splendid idea of using a 
dma-fence-chain to initially coalesce fences, I'd hit the same problem 
or risk illegaly joining two dma-fence-chains together.

To fix this, I would need to look at the incoming fences and iterate 
over any dma-fence-array or dma-fence-chain that is fed into the 
dma-fence-array to flatten out the input. In fact all dma-fence-array 
users would need to do that, and even dma-fence-chain users watching out 
for not joining chains together or accidently add an array that perhaps 
came as a disguised dma-fence from antother driver.

So the purpose to me would be to allow these containers as input to 
eachother without a lot of in-driver special-casing, be it by breaking 
recursion on built-in flattening to avoid

a) Hitting issues in the future or with existing interoperating drivers.
b) Avoid driver-private containers that also might break the 
interoperability. (For example the i915 currently driver-private 
dma_fence_work avoid all these problems, but we're attempting to address 
issues in common code rather than re-inventing stuff internally).

/Thomas


>
> Christian.
>
>>
>> /Thomas
>>
>>
>>>
>>> Christian.
>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> /Thomas
>>>>
>>>>

Christian König Dec. 1, 2021, 11:25 a.m. UTC | #17

Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
>
> On 12/1/21 11:32, Christian König wrote:
>> Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
>>> [SNIP]
>>>>
>>>> What we could do is to avoid all this by not calling the callback 
>>>> with the lock held in the first place.
>>>
>>> If that's possible that might be a good idea, pls also see below.
>>
>> The problem with that is 
>> dma_fence_signal_locked()/dma_fence_signal_timestamp_locked(). If we 
>> could avoid using that or at least allow it to drop the lock then we 
>> could call the callback without holding it.
>>
>> Somebody would need to audit the drivers and see if holding the lock 
>> is really necessary anywhere.
>>
>>>>
>>>>>>
>>>>>>>>
>>>>>>>> /Thomas
>>>>>>>
>>>>>>> Oh, and a follow up question:
>>>>>>>
>>>>>>> If there was a way to break the recursion on final put() (using 
>>>>>>> the same basic approach as patch 2 in this series uses to break 
>>>>>>> recursion in enable_signaling()), so that none of these 
>>>>>>> containers did require any special treatment, would it be worth 
>>>>>>> pursuing? I guess it might be possible by having the callbacks 
>>>>>>> drop the references rather than the loop in the final put. + a 
>>>>>>> couple of changes in code iterating over the fence pointers.
>>>>>>
>>>>>> That won't really help, you just move the recursion from the 
>>>>>> final put into the callback.
>>>>>
>>>>> How do we recurse from the callback? The introduced fence_put() of 
>>>>> individual fence pointers
>>>>> doesn't recurse anymore (at most 1 level), and any callback 
>>>>> recursion is broken by the irq_work?
>>>>
>>>> Yeah, but then you would need to take another lock to avoid racing 
>>>> with dma_fence_array_signaled().
>>>>
>>>>>
>>>>> I figure the big amount of work would be to adjust code that 
>>>>> iterates over the individual fence pointers to recognize that they 
>>>>> are rcu protected.
>>>>
>>>> Could be that we could solve this with RCU, but that sounds like a 
>>>> lot of churn for no gain at all.
>>>>
>>>> In other words even with the problems solved I think it would be a 
>>>> really bad idea to allow chaining of dma_fence_array objects.
>>>
>>> Yes, that was really the question, Is it worth pursuing this? I'm 
>>> not really suggesting we should allow this as an intentional 
>>> feature. I'm worried, however, that if we allow these containers to 
>>> start floating around cross-driver (or even internally) disguised as 
>>> ordinary dma_fences, they would require a lot of driver special 
>>> casing, or else completely unexpeced WARN_ON()s and lockdep splats 
>>> would start to turn up, scaring people off from using them. And that 
>>> would be a breeding ground for hairy driver-private constructs.
>>
>> Well the question is why we would want to do it?
>>
>> If it's to avoid inter driver lock dependencies by avoiding to call 
>> the callback with the spinlock held, then yes please. We had tons of 
>> problems with that, resulting in irq_work and work_item delegation 
>> all over the place.
>
> Yes, that sounds like something desirable, but in these containers, 
> what's causing the lock dependencies is the enable_signaling() 
> callback that is typically called locked.
>
>
>>
>> If it's to allow nesting of dma_fence_array instances, then it's most 
>> likely a really bad idea even if we fix all the locking order problems.
>
> Well I think my use-case where I hit a dead end may illustrate what 
> worries me here:
>
> 1) We use a dma-fence-array to coalesce all dependencies for ttm 
> object migration.
> 2) We use a dma-fence-chain to order the resulting dm_fence into a 
> timeline because the TTM resource manager code requires that.
>
> Initially seemingly harmless to me.
>
> But after a sequence evict->alloc->clear, the dma-fence-chain feeds 
> into the dma-fence-array for the clearing operation. Code still works 
> fine, and no deep recursion, no warnings. But if I were to add another 
> driver to the system that instead feeds a dma-fence-array into a 
> dma-fence-chain, this would give me a lockdep splat.
>
> So then if somebody were to come up with the splendid idea of using a 
> dma-fence-chain to initially coalesce fences, I'd hit the same problem 
> or risk illegaly joining two dma-fence-chains together.
>
> To fix this, I would need to look at the incoming fences and iterate 
> over any dma-fence-array or dma-fence-chain that is fed into the 
> dma-fence-array to flatten out the input. In fact all dma-fence-array 
> users would need to do that, and even dma-fence-chain users watching 
> out for not joining chains together or accidently add an array that 
> perhaps came as a disguised dma-fence from antother driver.
>
> So the purpose to me would be to allow these containers as input to 
> eachother without a lot of in-driver special-casing, be it by breaking 
> recursion on built-in flattening to avoid
>
> a) Hitting issues in the future or with existing interoperating drivers.
> b) Avoid driver-private containers that also might break the 
> interoperability. (For example the i915 currently driver-private 
> dma_fence_work avoid all these problems, but we're attempting to 
> address issues in common code rather than re-inventing stuff internally).

I don't think that a dma_fence_array or dma_fence_chain is the right 
thing to begin with in those use cases.

When you want to coalesce the dependencies for a job you could either 
use an xarray like Daniel did for the scheduler or some hashtable like 
we use in amdgpu. But I don't see the need for exposing the dma_fence 
interface for those.

And why do you use dma_fence_chain to generate a timeline for TTM? That 
should come naturally because all the moves must be ordered.

Regards,
Christian.

Thomas Hellström (Intel) Dec. 1, 2021, 12:16 p.m. UTC | #18

On 12/1/21 12:25, Christian König wrote:
> Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
>>
>> On 12/1/21 11:32, Christian König wrote:
>>> Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
>>>> [SNIP]
>>>>>
>>>>> What we could do is to avoid all this by not calling the callback 
>>>>> with the lock held in the first place.
>>>>
>>>> If that's possible that might be a good idea, pls also see below.
>>>
>>> The problem with that is 
>>> dma_fence_signal_locked()/dma_fence_signal_timestamp_locked(). If we 
>>> could avoid using that or at least allow it to drop the lock then we 
>>> could call the callback without holding it.
>>>
>>> Somebody would need to audit the drivers and see if holding the lock 
>>> is really necessary anywhere.
>>>
>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> /Thomas
>>>>>>>>
>>>>>>>> Oh, and a follow up question:
>>>>>>>>
>>>>>>>> If there was a way to break the recursion on final put() (using 
>>>>>>>> the same basic approach as patch 2 in this series uses to break 
>>>>>>>> recursion in enable_signaling()), so that none of these 
>>>>>>>> containers did require any special treatment, would it be worth 
>>>>>>>> pursuing? I guess it might be possible by having the callbacks 
>>>>>>>> drop the references rather than the loop in the final put. + a 
>>>>>>>> couple of changes in code iterating over the fence pointers.
>>>>>>>
>>>>>>> That won't really help, you just move the recursion from the 
>>>>>>> final put into the callback.
>>>>>>
>>>>>> How do we recurse from the callback? The introduced fence_put() 
>>>>>> of individual fence pointers
>>>>>> doesn't recurse anymore (at most 1 level), and any callback 
>>>>>> recursion is broken by the irq_work?
>>>>>
>>>>> Yeah, but then you would need to take another lock to avoid racing 
>>>>> with dma_fence_array_signaled().
>>>>>
>>>>>>
>>>>>> I figure the big amount of work would be to adjust code that 
>>>>>> iterates over the individual fence pointers to recognize that 
>>>>>> they are rcu protected.
>>>>>
>>>>> Could be that we could solve this with RCU, but that sounds like a 
>>>>> lot of churn for no gain at all.
>>>>>
>>>>> In other words even with the problems solved I think it would be a 
>>>>> really bad idea to allow chaining of dma_fence_array objects.
>>>>
>>>> Yes, that was really the question, Is it worth pursuing this? I'm 
>>>> not really suggesting we should allow this as an intentional 
>>>> feature. I'm worried, however, that if we allow these containers to 
>>>> start floating around cross-driver (or even internally) disguised 
>>>> as ordinary dma_fences, they would require a lot of driver special 
>>>> casing, or else completely unexpeced WARN_ON()s and lockdep splats 
>>>> would start to turn up, scaring people off from using them. And 
>>>> that would be a breeding ground for hairy driver-private constructs.
>>>
>>> Well the question is why we would want to do it?
>>>
>>> If it's to avoid inter driver lock dependencies by avoiding to call 
>>> the callback with the spinlock held, then yes please. We had tons of 
>>> problems with that, resulting in irq_work and work_item delegation 
>>> all over the place.
>>
>> Yes, that sounds like something desirable, but in these containers, 
>> what's causing the lock dependencies is the enable_signaling() 
>> callback that is typically called locked.
>>
>>
>>>
>>> If it's to allow nesting of dma_fence_array instances, then it's 
>>> most likely a really bad idea even if we fix all the locking order 
>>> problems.
>>
>> Well I think my use-case where I hit a dead end may illustrate what 
>> worries me here:
>>
>> 1) We use a dma-fence-array to coalesce all dependencies for ttm 
>> object migration.
>> 2) We use a dma-fence-chain to order the resulting dm_fence into a 
>> timeline because the TTM resource manager code requires that.
>>
>> Initially seemingly harmless to me.
>>
>> But after a sequence evict->alloc->clear, the dma-fence-chain feeds 
>> into the dma-fence-array for the clearing operation. Code still works 
>> fine, and no deep recursion, no warnings. But if I were to add 
>> another driver to the system that instead feeds a dma-fence-array 
>> into a dma-fence-chain, this would give me a lockdep splat.
>>
>> So then if somebody were to come up with the splendid idea of using a 
>> dma-fence-chain to initially coalesce fences, I'd hit the same 
>> problem or risk illegaly joining two dma-fence-chains together.
>>
>> To fix this, I would need to look at the incoming fences and iterate 
>> over any dma-fence-array or dma-fence-chain that is fed into the 
>> dma-fence-array to flatten out the input. In fact all dma-fence-array 
>> users would need to do that, and even dma-fence-chain users watching 
>> out for not joining chains together or accidently add an array that 
>> perhaps came as a disguised dma-fence from antother driver.
>>
>> So the purpose to me would be to allow these containers as input to 
>> eachother without a lot of in-driver special-casing, be it by 
>> breaking recursion on built-in flattening to avoid
>>
>> a) Hitting issues in the future or with existing interoperating drivers.
>> b) Avoid driver-private containers that also might break the 
>> interoperability. (For example the i915 currently driver-private 
>> dma_fence_work avoid all these problems, but we're attempting to 
>> address issues in common code rather than re-inventing stuff 
>> internally).
>
> I don't think that a dma_fence_array or dma_fence_chain is the right 
> thing to begin with in those use cases.
>
> When you want to coalesce the dependencies for a job you could either 
> use an xarray like Daniel did for the scheduler or some hashtable like 
> we use in amdgpu. But I don't see the need for exposing the dma_fence 
> interface for those.

This is because the interface to our migration code takes just a single 
dma-fence as dependency. Now this is of course something we need to look 
at to mitigate this, but see below.

>
> And why do you use dma_fence_chain to generate a timeline for TTM? 
> That should come naturally because all the moves must be ordered.

Oh, in this case because we're looking at adding stuff at the end of 
migration (like coalescing object shared fences and / or async unbind 
fences), which may not complete in order.

But that's not really the point, the point was that an (at least to me) 
seemingly harmless usage pattern, be it real or fictious, ends up giving 
you severe internal- or cross-driver headaches.

/Thomas


>
> Regards,
> Christian.
>
>

Christian König Dec. 3, 2021, 1:08 p.m. UTC | #19

Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
>
> On 12/1/21 12:25, Christian König wrote:
>> Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
>>>
>>> On 12/1/21 11:32, Christian König wrote:
>>>> Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
>>>>> [SNIP]
>>>>>>
>>>>>> What we could do is to avoid all this by not calling the callback 
>>>>>> with the lock held in the first place.
>>>>>
>>>>> If that's possible that might be a good idea, pls also see below.
>>>>
>>>> The problem with that is 
>>>> dma_fence_signal_locked()/dma_fence_signal_timestamp_locked(). If 
>>>> we could avoid using that or at least allow it to drop the lock 
>>>> then we could call the callback without holding it.
>>>>
>>>> Somebody would need to audit the drivers and see if holding the 
>>>> lock is really necessary anywhere.
>>>>
>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /Thomas
>>>>>>>>>
>>>>>>>>> Oh, and a follow up question:
>>>>>>>>>
>>>>>>>>> If there was a way to break the recursion on final put() 
>>>>>>>>> (using the same basic approach as patch 2 in this series uses 
>>>>>>>>> to break recursion in enable_signaling()), so that none of 
>>>>>>>>> these containers did require any special treatment, would it 
>>>>>>>>> be worth pursuing? I guess it might be possible by having the 
>>>>>>>>> callbacks drop the references rather than the loop in the 
>>>>>>>>> final put. + a couple of changes in code iterating over the 
>>>>>>>>> fence pointers.
>>>>>>>>
>>>>>>>> That won't really help, you just move the recursion from the 
>>>>>>>> final put into the callback.
>>>>>>>
>>>>>>> How do we recurse from the callback? The introduced fence_put() 
>>>>>>> of individual fence pointers
>>>>>>> doesn't recurse anymore (at most 1 level), and any callback 
>>>>>>> recursion is broken by the irq_work?
>>>>>>
>>>>>> Yeah, but then you would need to take another lock to avoid 
>>>>>> racing with dma_fence_array_signaled().
>>>>>>
>>>>>>>
>>>>>>> I figure the big amount of work would be to adjust code that 
>>>>>>> iterates over the individual fence pointers to recognize that 
>>>>>>> they are rcu protected.
>>>>>>
>>>>>> Could be that we could solve this with RCU, but that sounds like 
>>>>>> a lot of churn for no gain at all.
>>>>>>
>>>>>> In other words even with the problems solved I think it would be 
>>>>>> a really bad idea to allow chaining of dma_fence_array objects.
>>>>>
>>>>> Yes, that was really the question, Is it worth pursuing this? I'm 
>>>>> not really suggesting we should allow this as an intentional 
>>>>> feature. I'm worried, however, that if we allow these containers 
>>>>> to start floating around cross-driver (or even internally) 
>>>>> disguised as ordinary dma_fences, they would require a lot of 
>>>>> driver special casing, or else completely unexpeced WARN_ON()s and 
>>>>> lockdep splats would start to turn up, scaring people off from 
>>>>> using them. And that would be a breeding ground for hairy 
>>>>> driver-private constructs.
>>>>
>>>> Well the question is why we would want to do it?
>>>>
>>>> If it's to avoid inter driver lock dependencies by avoiding to call 
>>>> the callback with the spinlock held, then yes please. We had tons 
>>>> of problems with that, resulting in irq_work and work_item 
>>>> delegation all over the place.
>>>
>>> Yes, that sounds like something desirable, but in these containers, 
>>> what's causing the lock dependencies is the enable_signaling() 
>>> callback that is typically called locked.
>>>
>>>
>>>>
>>>> If it's to allow nesting of dma_fence_array instances, then it's 
>>>> most likely a really bad idea even if we fix all the locking order 
>>>> problems.
>>>
>>> Well I think my use-case where I hit a dead end may illustrate what 
>>> worries me here:
>>>
>>> 1) We use a dma-fence-array to coalesce all dependencies for ttm 
>>> object migration.
>>> 2) We use a dma-fence-chain to order the resulting dm_fence into a 
>>> timeline because the TTM resource manager code requires that.
>>>
>>> Initially seemingly harmless to me.
>>>
>>> But after a sequence evict->alloc->clear, the dma-fence-chain feeds 
>>> into the dma-fence-array for the clearing operation. Code still 
>>> works fine, and no deep recursion, no warnings. But if I were to add 
>>> another driver to the system that instead feeds a dma-fence-array 
>>> into a dma-fence-chain, this would give me a lockdep splat.
>>>
>>> So then if somebody were to come up with the splendid idea of using 
>>> a dma-fence-chain to initially coalesce fences, I'd hit the same 
>>> problem or risk illegaly joining two dma-fence-chains together.
>>>
>>> To fix this, I would need to look at the incoming fences and iterate 
>>> over any dma-fence-array or dma-fence-chain that is fed into the 
>>> dma-fence-array to flatten out the input. In fact all 
>>> dma-fence-array users would need to do that, and even 
>>> dma-fence-chain users watching out for not joining chains together 
>>> or accidently add an array that perhaps came as a disguised 
>>> dma-fence from antother driver.
>>>
>>> So the purpose to me would be to allow these containers as input to 
>>> eachother without a lot of in-driver special-casing, be it by 
>>> breaking recursion on built-in flattening to avoid
>>>
>>> a) Hitting issues in the future or with existing interoperating 
>>> drivers.
>>> b) Avoid driver-private containers that also might break the 
>>> interoperability. (For example the i915 currently driver-private 
>>> dma_fence_work avoid all these problems, but we're attempting to 
>>> address issues in common code rather than re-inventing stuff 
>>> internally).
>>
>> I don't think that a dma_fence_array or dma_fence_chain is the right 
>> thing to begin with in those use cases.
>>
>> When you want to coalesce the dependencies for a job you could either 
>> use an xarray like Daniel did for the scheduler or some hashtable 
>> like we use in amdgpu. But I don't see the need for exposing the 
>> dma_fence interface for those.
>
> This is because the interface to our migration code takes just a 
> single dma-fence as dependency. Now this is of course something we 
> need to look at to mitigate this, but see below.

Yeah, that's actually fine.

>>
>> And why do you use dma_fence_chain to generate a timeline for TTM? 
>> That should come naturally because all the moves must be ordered.
>
> Oh, in this case because we're looking at adding stuff at the end of 
> migration (like coalescing object shared fences and / or async unbind 
> fences), which may not complete in order.

Well that's ok as well. My question is why does this single dma_fence 
then shows up in the dma_fence_chain representing the whole migration?

That somehow doesn't seem to make sense because each individual step of 
the migration needs to wait for those dependencies as well even when it 
runs in parallel.

> But that's not really the point, the point was that an (at least to 
> me) seemingly harmless usage pattern, be it real or fictious, ends up 
> giving you severe internal- or cross-driver headaches.

Yeah, we probably should document that better. But in general I don't 
see much reason to allow mixing containers. The dma_fence_array and 
dma_fence_chain objects have some distinct use cases and and using them 
to build up larger dependency structures sounds really questionable.

Christian.

>
> /Thomas
>
>
>>
>> Regards,
>> Christian.
>>
>>

Thomas Hellstrom Dec. 3, 2021, 2:18 p.m. UTC | #20

On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
> Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
> > 
> > On 12/1/21 12:25, Christian König wrote:
> > > Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
> > > > 
> > > > On 12/1/21 11:32, Christian König wrote:
> > > > > Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
> > > > > > [SNIP]
> > > > > > > 
> > > > > > > What we could do is to avoid all this by not calling the
> > > > > > > callback 
> > > > > > > with the lock held in the first place.
> > > > > > 
> > > > > > If that's possible that might be a good idea, pls also see
> > > > > > below.
> > > > > 
> > > > > The problem with that is 
> > > > > dma_fence_signal_locked()/dma_fence_signal_timestamp_locked()
> > > > > . If 
> > > > > we could avoid using that or at least allow it to drop the
> > > > > lock 
> > > > > then we could call the callback without holding it.
> > > > > 
> > > > > Somebody would need to audit the drivers and see if holding
> > > > > the 
> > > > > lock is really necessary anywhere.
> > > > > 
> > > > > > > 
> > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > /Thomas
> > > > > > > > > > 
> > > > > > > > > > Oh, and a follow up question:
> > > > > > > > > > 
> > > > > > > > > > If there was a way to break the recursion on final
> > > > > > > > > > put() 
> > > > > > > > > > (using the same basic approach as patch 2 in this
> > > > > > > > > > series uses 
> > > > > > > > > > to break recursion in enable_signaling()), so that
> > > > > > > > > > none of 
> > > > > > > > > > these containers did require any special treatment,
> > > > > > > > > > would it 
> > > > > > > > > > be worth pursuing? I guess it might be possible by
> > > > > > > > > > having the 
> > > > > > > > > > callbacks drop the references rather than the loop
> > > > > > > > > > in the 
> > > > > > > > > > final put. + a couple of changes in code iterating
> > > > > > > > > > over the 
> > > > > > > > > > fence pointers.
> > > > > > > > > 
> > > > > > > > > That won't really help, you just move the recursion
> > > > > > > > > from the 
> > > > > > > > > final put into the callback.
> > > > > > > > 
> > > > > > > > How do we recurse from the callback? The introduced
> > > > > > > > fence_put() 
> > > > > > > > of individual fence pointers
> > > > > > > > doesn't recurse anymore (at most 1 level), and any
> > > > > > > > callback 
> > > > > > > > recursion is broken by the irq_work?
> > > > > > > 
> > > > > > > Yeah, but then you would need to take another lock to
> > > > > > > avoid 
> > > > > > > racing with dma_fence_array_signaled().
> > > > > > > 
> > > > > > > > 
> > > > > > > > I figure the big amount of work would be to adjust code
> > > > > > > > that 
> > > > > > > > iterates over the individual fence pointers to
> > > > > > > > recognize that 
> > > > > > > > they are rcu protected.
> > > > > > > 
> > > > > > > Could be that we could solve this with RCU, but that
> > > > > > > sounds like 
> > > > > > > a lot of churn for no gain at all.
> > > > > > > 
> > > > > > > In other words even with the problems solved I think it
> > > > > > > would be 
> > > > > > > a really bad idea to allow chaining of dma_fence_array
> > > > > > > objects.
> > > > > > 
> > > > > > Yes, that was really the question, Is it worth pursuing
> > > > > > this? I'm 
> > > > > > not really suggesting we should allow this as an
> > > > > > intentional 
> > > > > > feature. I'm worried, however, that if we allow these
> > > > > > containers 
> > > > > > to start floating around cross-driver (or even internally) 
> > > > > > disguised as ordinary dma_fences, they would require a lot
> > > > > > of 
> > > > > > driver special casing, or else completely unexpeced
> > > > > > WARN_ON()s and 
> > > > > > lockdep splats would start to turn up, scaring people off
> > > > > > from 
> > > > > > using them. And that would be a breeding ground for hairy 
> > > > > > driver-private constructs.
> > > > > 
> > > > > Well the question is why we would want to do it?
> > > > > 
> > > > > If it's to avoid inter driver lock dependencies by avoiding
> > > > > to call 
> > > > > the callback with the spinlock held, then yes please. We had
> > > > > tons 
> > > > > of problems with that, resulting in irq_work and work_item 
> > > > > delegation all over the place.
> > > > 
> > > > Yes, that sounds like something desirable, but in these
> > > > containers, 
> > > > what's causing the lock dependencies is the enable_signaling() 
> > > > callback that is typically called locked.
> > > > 
> > > > 
> > > > > 
> > > > > If it's to allow nesting of dma_fence_array instances, then
> > > > > it's 
> > > > > most likely a really bad idea even if we fix all the locking
> > > > > order 
> > > > > problems.
> > > > 
> > > > Well I think my use-case where I hit a dead end may illustrate
> > > > what 
> > > > worries me here:
> > > > 
> > > > 1) We use a dma-fence-array to coalesce all dependencies for
> > > > ttm 
> > > > object migration.
> > > > 2) We use a dma-fence-chain to order the resulting dm_fence
> > > > into a 
> > > > timeline because the TTM resource manager code requires that.
> > > > 
> > > > Initially seemingly harmless to me.
> > > > 
> > > > But after a sequence evict->alloc->clear, the dma-fence-chain
> > > > feeds 
> > > > into the dma-fence-array for the clearing operation. Code still
> > > > works fine, and no deep recursion, no warnings. But if I were
> > > > to add 
> > > > another driver to the system that instead feeds a dma-fence-
> > > > array 
> > > > into a dma-fence-chain, this would give me a lockdep splat.
> > > > 
> > > > So then if somebody were to come up with the splendid idea of
> > > > using 
> > > > a dma-fence-chain to initially coalesce fences, I'd hit the
> > > > same 
> > > > problem or risk illegaly joining two dma-fence-chains together.
> > > > 
> > > > To fix this, I would need to look at the incoming fences and
> > > > iterate 
> > > > over any dma-fence-array or dma-fence-chain that is fed into
> > > > the 
> > > > dma-fence-array to flatten out the input. In fact all 
> > > > dma-fence-array users would need to do that, and even 
> > > > dma-fence-chain users watching out for not joining chains
> > > > together 
> > > > or accidently add an array that perhaps came as a disguised 
> > > > dma-fence from antother driver.
> > > > 
> > > > So the purpose to me would be to allow these containers as
> > > > input to 
> > > > eachother without a lot of in-driver special-casing, be it by 
> > > > breaking recursion on built-in flattening to avoid
> > > > 
> > > > a) Hitting issues in the future or with existing interoperating
> > > > drivers.
> > > > b) Avoid driver-private containers that also might break the 
> > > > interoperability. (For example the i915 currently driver-
> > > > private 
> > > > dma_fence_work avoid all these problems, but we're attempting
> > > > to 
> > > > address issues in common code rather than re-inventing stuff 
> > > > internally).
> > > 
> > > I don't think that a dma_fence_array or dma_fence_chain is the
> > > right 
> > > thing to begin with in those use cases.
> > > 
> > > When you want to coalesce the dependencies for a job you could
> > > either 
> > > use an xarray like Daniel did for the scheduler or some hashtable
> > > like we use in amdgpu. But I don't see the need for exposing the 
> > > dma_fence interface for those.
> > 
> > This is because the interface to our migration code takes just a 
> > single dma-fence as dependency. Now this is of course something we 
> > need to look at to mitigate this, but see below.
> 
> Yeah, that's actually fine.
> 
> > > 
> > > And why do you use dma_fence_chain to generate a timeline for
> > > TTM? 
> > > That should come naturally because all the moves must be ordered.
> > 
> > Oh, in this case because we're looking at adding stuff at the end
> > of 
> > migration (like coalescing object shared fences and / or async
> > unbind 
> > fences), which may not complete in order.
> 
> Well that's ok as well. My question is why does this single dma_fence
> then shows up in the dma_fence_chain representing the whole
> migration?

What we'd like to happen during eviction is that we

1) await any exclusive- or moving fences, then schedule the migration
blit. The blit manages its own GPU ptes. Results in a single fence.
2) Schedule unbind of any gpu vmas, resulting possibly in multiple
fences.
3) Most but not all of the remaining resv shared fences will have been
finished in 2) We can't easily tell which so we have a couple of shared
fences left.
4) Add all fences resulting from 1) 2) and 3) into the per-memory-type
dma-fence-chain. 
5) hand the resulting dma-fence-chain representing the end of migration
over to ttm's resource manager. 

Now this means we have a dma-fence-chain disguised as a dma-fence out
in the wild, and it could in theory reappear as a 3) fence for another
migration unless a very careful audit is done, or as an input to the
dma-fence-array used for that single dependency.

> 
> That somehow doesn't seem to make sense because each individual step
> of 
> the migration needs to wait for those dependencies as well even when
> it 
> runs in parallel.
> 
> > But that's not really the point, the point was that an (at least to
> > me) seemingly harmless usage pattern, be it real or fictious, ends
> > up 
> > giving you severe internal- or cross-driver headaches.
> 
> Yeah, we probably should document that better. But in general I don't
> see much reason to allow mixing containers. The dma_fence_array and 
> dma_fence_chain objects have some distinct use cases and and using
> them 
> to build up larger dependency structures sounds really questionable.

Yes, I tend to agree to some extent here. Perhaps add warnings when
adding a chain or array as an input to array and when accidently
joining chains, and provide helpers for flattening if needed.

/Thomas


> 
> Christian.
> 
> > 
> > /Thomas
> > 
> > 
> > > 
> > > Regards,
> > > Christian.
> > > 
> > > 
>

Christian König Dec. 3, 2021, 2:26 p.m. UTC | #21

[Adding Daniel here as well]

Am 03.12.21 um 15:18 schrieb Thomas Hellström:
> [SNIP]
>> Well that's ok as well. My question is why does this single dma_fence
>> then shows up in the dma_fence_chain representing the whole
>> migration?
> What we'd like to happen during eviction is that we
>
> 1) await any exclusive- or moving fences, then schedule the migration
> blit. The blit manages its own GPU ptes. Results in a single fence.
> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
> fences.
> 3) Most but not all of the remaining resv shared fences will have been
> finished in 2) We can't easily tell which so we have a couple of shared
> fences left.

Stop, wait a second here. We are going a bit in circles.

Before you migrate a buffer, you *MUST* wait for all shared fences to 
complete. This is documented mandatory DMA-buf behavior.

Daniel and I have discussed that quite extensively in the last few month.

So how does it come that you do the blit before all shared fences are 
completed?

> 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type
> dma-fence-chain.
> 5) hand the resulting dma-fence-chain representing the end of migration
> over to ttm's resource manager.
>
> Now this means we have a dma-fence-chain disguised as a dma-fence out
> in the wild, and it could in theory reappear as a 3) fence for another
> migration unless a very careful audit is done, or as an input to the
> dma-fence-array used for that single dependency.
>
>> That somehow doesn't seem to make sense because each individual step
>> of
>> the migration needs to wait for those dependencies as well even when
>> it
>> runs in parallel.
>>
>>> But that's not really the point, the point was that an (at least to
>>> me) seemingly harmless usage pattern, be it real or fictious, ends
>>> up
>>> giving you severe internal- or cross-driver headaches.
>> Yeah, we probably should document that better. But in general I don't
>> see much reason to allow mixing containers. The dma_fence_array and
>> dma_fence_chain objects have some distinct use cases and and using
>> them
>> to build up larger dependency structures sounds really questionable.
> Yes, I tend to agree to some extent here. Perhaps add warnings when
> adding a chain or array as an input to array and when accidently
> joining chains, and provide helpers for flattening if needed.

Yeah, that's probably a really good idea. Going to put it on my todo list.

Thanks,
Christian.

>
> /Thomas
>
>
>> Christian.
>>
>>> /Thomas
>>>
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>
>

Thomas Hellstrom Dec. 3, 2021, 2:50 p.m. UTC | #22

On 12/3/21 15:26, Christian König wrote:
> [Adding Daniel here as well]
>
> Am 03.12.21 um 15:18 schrieb Thomas Hellström:
>> [SNIP]
>>> Well that's ok as well. My question is why does this single dma_fence
>>> then shows up in the dma_fence_chain representing the whole
>>> migration?
>> What we'd like to happen during eviction is that we
>>
>> 1) await any exclusive- or moving fences, then schedule the migration
>> blit. The blit manages its own GPU ptes. Results in a single fence.
>> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
>> fences.
>> 3) Most but not all of the remaining resv shared fences will have been
>> finished in 2) We can't easily tell which so we have a couple of shared
>> fences left.
>
> Stop, wait a second here. We are going a bit in circles.
>
> Before you migrate a buffer, you *MUST* wait for all shared fences to 
> complete. This is documented mandatory DMA-buf behavior.
>
> Daniel and I have discussed that quite extensively in the last few month.
>
> So how does it come that you do the blit before all shared fences are 
> completed?

Well we don't currently but wanted to... (I haven't consulted Daniel in 
the matter, tbh).

I was under the impression that all writes would add an exclusive fence 
to the dma_resv. If that's not the case or this is otherwise against the 
mandatory DMA-buf bevhavior, we can certainly keep that part as is and 
that would eliminate 3).

/Thomas

Christian König Dec. 3, 2021, 3 p.m. UTC | #23

Am 03.12.21 um 15:50 schrieb Thomas Hellström:
>
> On 12/3/21 15:26, Christian König wrote:
>> [Adding Daniel here as well]
>>
>> Am 03.12.21 um 15:18 schrieb Thomas Hellström:
>>> [SNIP]
>>>> Well that's ok as well. My question is why does this single dma_fence
>>>> then shows up in the dma_fence_chain representing the whole
>>>> migration?
>>> What we'd like to happen during eviction is that we
>>>
>>> 1) await any exclusive- or moving fences, then schedule the migration
>>> blit. The blit manages its own GPU ptes. Results in a single fence.
>>> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
>>> fences.
>>> 3) Most but not all of the remaining resv shared fences will have been
>>> finished in 2) We can't easily tell which so we have a couple of shared
>>> fences left.
>>
>> Stop, wait a second here. We are going a bit in circles.
>>
>> Before you migrate a buffer, you *MUST* wait for all shared fences to 
>> complete. This is documented mandatory DMA-buf behavior.
>>
>> Daniel and I have discussed that quite extensively in the last few 
>> month.
>>
>> So how does it come that you do the blit before all shared fences are 
>> completed?
>
> Well we don't currently but wanted to... (I haven't consulted Daniel 
> in the matter, tbh).
>
> I was under the impression that all writes would add an exclusive 
> fence to the dma_resv.

Yes that's correct. I'm working on to have more than one write fence, 
but that is currently under review.

> If that's not the case or this is otherwise against the mandatory 
> DMA-buf bevhavior, we can certainly keep that part as is and that 
> would eliminate 3).

Ah, now that somewhat starts to make sense.

So your blit only waits for the writes to finish before starting the 
blit. Yes that's legal as long as you don't change the original content 
with the blit.

But don't you then need to wait for both reads and writes before you 
unmap the VMAs?

Anyway the good news is your problem totally goes away with the DMA-resv 
rework I've already send out. Basically it is now possible to have more 
than one fence in the DMA-resv object for migrations and all existing 
fences are kept around until they are finished.

Regards,
Christian.

>
> /Thomas
>

Thomas Hellström (Intel) Dec. 3, 2021, 3:13 p.m. UTC | #24

On 12/3/21 16:00, Christian König wrote:
> Am 03.12.21 um 15:50 schrieb Thomas Hellström:
>>
>> On 12/3/21 15:26, Christian König wrote:
>>> [Adding Daniel here as well]
>>>
>>> Am 03.12.21 um 15:18 schrieb Thomas Hellström:
>>>> [SNIP]
>>>>> Well that's ok as well. My question is why does this single dma_fence
>>>>> then shows up in the dma_fence_chain representing the whole
>>>>> migration?
>>>> What we'd like to happen during eviction is that we
>>>>
>>>> 1) await any exclusive- or moving fences, then schedule the migration
>>>> blit. The blit manages its own GPU ptes. Results in a single fence.
>>>> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
>>>> fences.
>>>> 3) Most but not all of the remaining resv shared fences will have been
>>>> finished in 2) We can't easily tell which so we have a couple of 
>>>> shared
>>>> fences left.
>>>
>>> Stop, wait a second here. We are going a bit in circles.
>>>
>>> Before you migrate a buffer, you *MUST* wait for all shared fences 
>>> to complete. This is documented mandatory DMA-buf behavior.
>>>
>>> Daniel and I have discussed that quite extensively in the last few 
>>> month.
>>>
>>> So how does it come that you do the blit before all shared fences 
>>> are completed?
>>
>> Well we don't currently but wanted to... (I haven't consulted Daniel 
>> in the matter, tbh).
>>
>> I was under the impression that all writes would add an exclusive 
>> fence to the dma_resv.
>
> Yes that's correct. I'm working on to have more than one write fence, 
> but that is currently under review.
>
>> If that's not the case or this is otherwise against the mandatory 
>> DMA-buf bevhavior, we can certainly keep that part as is and that 
>> would eliminate 3).
>
> Ah, now that somewhat starts to make sense.
>
> So your blit only waits for the writes to finish before starting the 
> blit. Yes that's legal as long as you don't change the original 
> content with the blit.
>
> But don't you then need to wait for both reads and writes before you 
> unmap the VMAs?

Yes, but that's planned to be done all async, and those unbind jobs are 
scheduled simultaneosly with the blit, and the blit itself manages its 
own page-table-entries, so no need to unbind any blit vmas.

>
> Anyway the good news is your problem totally goes away with the 
> DMA-resv rework I've already send out. Basically it is now possible to 
> have more than one fence in the DMA-resv object for migrations and all 
> existing fences are kept around until they are finished.

Sounds good.

Thanks,

Thomas

Daniel Vetter Dec. 7, 2021, 6:08 p.m. UTC | #25

Once more an entire week behind on mails, but this looked interesting
enough.

On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote:
> On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
> > Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
> > > 
> > > On 12/1/21 12:25, Christian König wrote:
> > > > And why do you use dma_fence_chain to generate a timeline for
> > > > TTM? 
> > > > That should come naturally because all the moves must be ordered.
> > > 
> > > Oh, in this case because we're looking at adding stuff at the end
> > > of 
> > > migration (like coalescing object shared fences and / or async
> > > unbind 
> > > fences), which may not complete in order.
> > 
> > Well that's ok as well. My question is why does this single dma_fence
> > then shows up in the dma_fence_chain representing the whole
> > migration?
> 
> What we'd like to happen during eviction is that we
> 
> 1) await any exclusive- or moving fences, then schedule the migration
> blit. The blit manages its own GPU ptes. Results in a single fence.
> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
> fences.

This sounds like over-optimizing for nothing. We only really care about
pipeling moves on dgpu, and on dgpu we only care about modern userspace
(because even gl moves in that direction).

And modern means that usually even write access is only setting a read
fence, because in vk/compute we only set write fences for object which
need implicit sync, and _only_ when actually needed.

So ignoring read fences for movings "because it's only reads" is actually
busted.

I think for buffer moves we should document and enforce (in review) the
rule that you have to wait for all fences, otherwise boom. Same really
like before freeing backing storage. Otherwise there's just too many gaps
and surprises.

And yes with Christian's rework of dma_resv this will change, and we'll
allow multiple write fences (because that's what amdgpu encoded into their
uapi). Still means that you cannot move a buffer without waiting for read
fences (or kernel fences or anything really).

The other thing is this entire spinlock recursion topic for dma_fence, and
I'm deeply unhappy about the truckload of tricks i915 plays and hence in
favour of avoiding recursion in this area as much as possible.

If we really can't avoid it then irq_work to get a new clean context gets
the job done. Making this messy and work is imo a feature, lock nesting of
same level locks is just not a good&robust engineering idea.

/me back to being completely burried

I do hope I can find some more time to review a few more of Christian's
patches this week though :-/

Cheers, Daniel

> 3) Most but not all of the remaining resv shared fences will have been
> finished in 2) We can't easily tell which so we have a couple of shared
> fences left.
> 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type
> dma-fence-chain. 
> 5) hand the resulting dma-fence-chain representing the end of migration
> over to ttm's resource manager. 
> 
> Now this means we have a dma-fence-chain disguised as a dma-fence out
> in the wild, and it could in theory reappear as a 3) fence for another
> migration unless a very careful audit is done, or as an input to the
> dma-fence-array used for that single dependency.
> 
> > 
> > That somehow doesn't seem to make sense because each individual step
> > of 
> > the migration needs to wait for those dependencies as well even when
> > it 
> > runs in parallel.
> > 
> > > But that's not really the point, the point was that an (at least to
> > > me) seemingly harmless usage pattern, be it real or fictious, ends
> > > up 
> > > giving you severe internal- or cross-driver headaches.
> > 
> > Yeah, we probably should document that better. But in general I don't
> > see much reason to allow mixing containers. The dma_fence_array and 
> > dma_fence_chain objects have some distinct use cases and and using
> > them 
> > to build up larger dependency structures sounds really questionable.
> 
> Yes, I tend to agree to some extent here. Perhaps add warnings when
> adding a chain or array as an input to array and when accidently
> joining chains, and provide helpers for flattening if needed.
> 
> /Thomas
> 
> 
> > 
> > Christian.
> > 
> > > 
> > > /Thomas
> > > 
> > > 
> > > > 
> > > > Regards,
> > > > Christian.
> > > > 
> > > > 
> > 
> 
>

Thomas Hellstrom Dec. 7, 2021, 8:46 p.m. UTC | #26

On 12/7/21 19:08, Daniel Vetter wrote:
> Once more an entire week behind on mails, but this looked interesting
> enough.
>
> On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote:
>> On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
>>> Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
>>>> On 12/1/21 12:25, Christian König wrote:
>>>>> And why do you use dma_fence_chain to generate a timeline for
>>>>> TTM?
>>>>> That should come naturally because all the moves must be ordered.
>>>> Oh, in this case because we're looking at adding stuff at the end
>>>> of
>>>> migration (like coalescing object shared fences and / or async
>>>> unbind
>>>> fences), which may not complete in order.
>>> Well that's ok as well. My question is why does this single dma_fence
>>> then shows up in the dma_fence_chain representing the whole
>>> migration?
>> What we'd like to happen during eviction is that we
>>
>> 1) await any exclusive- or moving fences, then schedule the migration
>> blit. The blit manages its own GPU ptes. Results in a single fence.
>> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
>> fences.
> This sounds like over-optimizing for nothing. We only really care about
> pipeling moves on dgpu, and on dgpu we only care about modern userspace
> (because even gl moves in that direction).
Hmm. It's not totally clear what you mean with over-optimizing for 
nothing, is it the fact that we want to start the blit before all shared 
fences have signaled or the fact that we're doing async unbinding to 
avoid a synchronization point that stops us from fully pipelining evictions?
> And modern means that usually even write access is only setting a read
> fence, because in vk/compute we only set write fences for object which
> need implicit sync, and _only_ when actually needed.
>
> So ignoring read fences for movings "because it's only reads" is actually
> busted.

I'm fine with awaiting also shared fences before we start the blit, as 
mentioned also later in the thread, but that is just a matter of when we 
coalesce the shared fences. So since difference in complexity is 
minimal, what's viewed as optimizing for nothing can also be conversely 
be viewed as unneccesarily waiting for nothing, blocking the migration 
context timeline from progressing with unrelated blits. (Unless there 
are correctness issues of course, see below).

But not setting a write fence after write seems to conflict with dma-buf 
rules as also discussed later in the thread. Perhaps some clarity is 
needed here. How would a writer or reader that implicitly *wants* to 
wait for previous writers go about doing that?

Note that what we're doing is not "moving" in the sense that we're 
giving up or modifying the old storage but rather start a blit assuming 
that the contents of the old storage is stable, or the writer doesn't care.

>
> I think for buffer moves we should document and enforce (in review) the
> rule that you have to wait for all fences, otherwise boom. Same really
> like before freeing backing storage. Otherwise there's just too many gaps
> and surprises.
>
> And yes with Christian's rework of dma_resv this will change, and we'll
> allow multiple write fences (because that's what amdgpu encoded into their
> uapi). Still means that you cannot move a buffer without waiting for read
> fences (or kernel fences or anything really).

Sounds like some agreement is needed here what rules we actually should 
obey. As mentioned above I'm fine with either.

>
> The other thing is this entire spinlock recursion topic for dma_fence, and
> I'm deeply unhappy about the truckload of tricks i915 plays and hence in
> favour of avoiding recursion in this area as much as possible.

TBH I think the i915 corresponding container manages to avoid both the 
deep recursive calls and lock nesting simply by early enable_signaling() 
and not storing the fence pointers of the array fences, which to me 
appears to be a simple and clean approach. No tricks there.

>
> If we really can't avoid it then irq_work to get a new clean context gets
> the job done. Making this messy and work is imo a feature, lock nesting of
> same level locks is just not a good&robust engineering idea.

For the dma-fence-chain and dma-fence-array there are four possibilities 
moving forward:

1) Keeping the current same-level locking nesting order of 
container-first containee later. This is fully annotated, but fragile 
and blows up if users attempt to nest containers in different orders.

2) Establishing a reverse-signaling locking order. Not annotatable. 
blows up on signal-on-any.

3) Early enable-signaling, no lock nesting, low latency but possibly 
unnecessary enable_signaling calls.

4) irq_work in enable_signaling(). High latency.

The tread finally agreed the solution would be to keep 1), add early 
warnings for the pitfalls and if possible provide helpers to flatten to 
avoid container recursion.

/Thomas


>
> /me back to being completely burried
>
> I do hope I can find some more time to review a few more of Christian's
> patches this week though :-/
>
> Cheers, Daniel
>
>> 3) Most but not all of the remaining resv shared fences will have been
>> finished in 2) We can't easily tell which so we have a couple of shared
>> fences left.
>> 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type
>> dma-fence-chain.
>> 5) hand the resulting dma-fence-chain representing the end of migration
>> over to ttm's resource manager.
>>
>> Now this means we have a dma-fence-chain disguised as a dma-fence out
>> in the wild, and it could in theory reappear as a 3) fence for another
>> migration unless a very careful audit is done, or as an input to the
>> dma-fence-array used for that single dependency.
>>
>>> That somehow doesn't seem to make sense because each individual step
>>> of
>>> the migration needs to wait for those dependencies as well even when
>>> it
>>> runs in parallel.
>>>
>>>> But that's not really the point, the point was that an (at least to
>>>> me) seemingly harmless usage pattern, be it real or fictious, ends
>>>> up
>>>> giving you severe internal- or cross-driver headaches.
>>> Yeah, we probably should document that better. But in general I don't
>>> see much reason to allow mixing containers. The dma_fence_array and
>>> dma_fence_chain objects have some distinct use cases and and using
>>> them
>>> to build up larger dependency structures sounds really questionable.
>> Yes, I tend to agree to some extent here. Perhaps add warnings when
>> adding a chain or array as an input to array and when accidently
>> joining chains, and provide helpers for flattening if needed.
>>
>> /Thomas
>>
>>
>>> Christian.
>>>
>>>> /Thomas
>>>>
>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>
>>

Daniel Vetter Dec. 20, 2021, 9:37 a.m. UTC | #27

On Tue, Dec 07, 2021 at 09:46:47PM +0100, Thomas Hellström wrote:
> 
> On 12/7/21 19:08, Daniel Vetter wrote:
> > Once more an entire week behind on mails, but this looked interesting
> > enough.
> > 
> > On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote:
> > > On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
> > > > Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
> > > > > On 12/1/21 12:25, Christian König wrote:
> > > > > > And why do you use dma_fence_chain to generate a timeline for
> > > > > > TTM?
> > > > > > That should come naturally because all the moves must be ordered.
> > > > > Oh, in this case because we're looking at adding stuff at the end
> > > > > of
> > > > > migration (like coalescing object shared fences and / or async
> > > > > unbind
> > > > > fences), which may not complete in order.
> > > > Well that's ok as well. My question is why does this single dma_fence
> > > > then shows up in the dma_fence_chain representing the whole
> > > > migration?
> > > What we'd like to happen during eviction is that we
> > > 
> > > 1) await any exclusive- or moving fences, then schedule the migration
> > > blit. The blit manages its own GPU ptes. Results in a single fence.
> > > 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
> > > fences.
> > This sounds like over-optimizing for nothing. We only really care about
> > pipeling moves on dgpu, and on dgpu we only care about modern userspace
> > (because even gl moves in that direction).
> Hmm. It's not totally clear what you mean with over-optimizing for nothing,
> is it the fact that we want to start the blit before all shared fences have
> signaled or the fact that we're doing async unbinding to avoid a
> synchronization point that stops us from fully pipelining evictions?

Yup. Least because that breaks vulkan, so you really can't do this
optimizations :-)

In general I meant that unless you really, really understand everything
all the time (which frankly no one does), then trying to be clever just
isn't worth it. We have access pending in the dma_resv, we wait for it is
dumb, simple, no surprises.

> > And modern means that usually even write access is only setting a read
> > fence, because in vk/compute we only set write fences for object which
> > need implicit sync, and _only_ when actually needed.
> > 
> > So ignoring read fences for movings "because it's only reads" is actually
> > busted.
> 
> I'm fine with awaiting also shared fences before we start the blit, as
> mentioned also later in the thread, but that is just a matter of when we
> coalesce the shared fences. So since difference in complexity is minimal,
> what's viewed as optimizing for nothing can also be conversely be viewed as
> unneccesarily waiting for nothing, blocking the migration context timeline
> from progressing with unrelated blits. (Unless there are correctness issues
> of course, see below).
> 
> But not setting a write fence after write seems to conflict with dma-buf
> rules as also discussed later in the thread. Perhaps some clarity is needed
> here. How would a writer or reader that implicitly *wants* to wait for
> previous writers go about doing that?
> 
> Note that what we're doing is not "moving" in the sense that we're giving up
> or modifying the old storage but rather start a blit assuming that the
> contents of the old storage is stable, or the writer doesn't care.

Yeah that's not how dma-buf works, and which is what Christian is trying
to rectify with his huge refactoring/doc series to give a bit clearer
meaning to what a fence in a dma_resv means.

> > I think for buffer moves we should document and enforce (in review) the
> > rule that you have to wait for all fences, otherwise boom. Same really
> > like before freeing backing storage. Otherwise there's just too many gaps
> > and surprises.
> > 
> > And yes with Christian's rework of dma_resv this will change, and we'll
> > allow multiple write fences (because that's what amdgpu encoded into their
> > uapi). Still means that you cannot move a buffer without waiting for read
> > fences (or kernel fences or anything really).
> 
> Sounds like some agreement is needed here what rules we actually should
> obey. As mentioned above I'm fine with either.

I think it would be good to comment on the doc patch in Christian's series
for that. But essentially read/write don't mean actual read/write to
memory, but only read/write access in terms of implicit sync. Buffers
which do not partake in implicit sync (driver internal stuff) or access
which is not implicitly synced (anything vk does) do _not_ need to set a
write fence. They will (except amdgpu, until they fix their CS uapi)
_only_ set a read fence.

Christian and me had a multi-month discussion on this, so it's a bit
tricky.

> > The other thing is this entire spinlock recursion topic for dma_fence, and
> > I'm deeply unhappy about the truckload of tricks i915 plays and hence in
> > favour of avoiding recursion in this area as much as possible.
> 
> TBH I think the i915 corresponding container manages to avoid both the deep
> recursive calls and lock nesting simply by early enable_signaling() and not
> storing the fence pointers of the array fences, which to me appears to be a
> simple and clean approach. No tricks there.
> 
> > 
> > If we really can't avoid it then irq_work to get a new clean context gets
> > the job done. Making this messy and work is imo a feature, lock nesting of
> > same level locks is just not a good&robust engineering idea.
> 
> For the dma-fence-chain and dma-fence-array there are four possibilities
> moving forward:
> 
> 1) Keeping the current same-level locking nesting order of container-first
> containee later. This is fully annotated, but fragile and blows up if users
> attempt to nest containers in different orders.
> 
> 2) Establishing a reverse-signaling locking order. Not annotatable. blows up
> on signal-on-any.
> 
> 3) Early enable-signaling, no lock nesting, low latency but possibly
> unnecessary enable_signaling calls.
> 
> 4) irq_work in enable_signaling(). High latency.
> 
> The tread finally agreed the solution would be to keep 1), add early
> warnings for the pitfalls and if possible provide helpers to flatten to
> avoid container recursion.

Hm ok seems ok. It's definitely an area where we don't have great
solutions :-/
-Daniel

> 
> /Thomas
> 
> 
> > 
> > /me back to being completely burried
> > 
> > I do hope I can find some more time to review a few more of Christian's
> > patches this week though :-/
> > 
> > Cheers, Daniel
> > 
> > > 3) Most but not all of the remaining resv shared fences will have been
> > > finished in 2) We can't easily tell which so we have a couple of shared
> > > fences left.
> > > 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type
> > > dma-fence-chain.
> > > 5) hand the resulting dma-fence-chain representing the end of migration
> > > over to ttm's resource manager.
> > > 
> > > Now this means we have a dma-fence-chain disguised as a dma-fence out
> > > in the wild, and it could in theory reappear as a 3) fence for another
> > > migration unless a very careful audit is done, or as an input to the
> > > dma-fence-array used for that single dependency.
> > > 
> > > > That somehow doesn't seem to make sense because each individual step
> > > > of
> > > > the migration needs to wait for those dependencies as well even when
> > > > it
> > > > runs in parallel.
> > > > 
> > > > > But that's not really the point, the point was that an (at least to
> > > > > me) seemingly harmless usage pattern, be it real or fictious, ends
> > > > > up
> > > > > giving you severe internal- or cross-driver headaches.
> > > > Yeah, we probably should document that better. But in general I don't
> > > > see much reason to allow mixing containers. The dma_fence_array and
> > > > dma_fence_chain objects have some distinct use cases and and using
> > > > them
> > > > to build up larger dependency structures sounds really questionable.
> > > Yes, I tend to agree to some extent here. Perhaps add warnings when
> > > adding a chain or array as an input to array and when accidently
> > > joining chains, and provide helpers for flattening if needed.
> > > 
> > > /Thomas
> > > 
> > > 
> > > > Christian.
> > > > 
> > > > > /Thomas
> > > > > 
> > > > > 
> > > > > > Regards,
> > > > > > Christian.
> > > > > > 
> > > > > > 
> > >

Patch

diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c
index 3e07f961e2f3..0322b92909fe 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -84,8 +84,8 @@  static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
 		 * insufficient).
 		 */
 		dma_fence_get(&array->base);
-		if (dma_fence_add_callback(array->fences[i], &cb[i].cb,
-					   dma_fence_array_cb_func)) {
+		if (dma_fence_add_callback_nested(array->fences[i], &cb[i].cb,
+						  dma_fence_array_cb_func)) {
 			int error = array->fences[i]->error;
 
 			dma_fence_array_set_pending_error(array, error);
@@ -158,6 +158,7 @@  struct dma_fence_array *dma_fence_array_create(int num_fences,
 {
 	struct dma_fence_array *array;
 	size_t size = sizeof(*array);
+	struct dma_fence *fence;
 
 	/* Allocate the callback structures behind the array. */
 	size += num_fences * sizeof(struct dma_fence_array_cb);
@@ -165,8 +166,9 @@  struct dma_fence_array *dma_fence_array_create(int num_fences,
 	if (!array)
 		return NULL;
 
+	fence = &array->base;
 	spin_lock_init(&array->lock);
-	dma_fence_init(&array->base, &dma_fence_array_ops, &array->lock,
+	dma_fence_init(fence, &dma_fence_array_ops, &array->lock,
 		       context, seqno);
 	init_irq_work(&array->work, irq_dma_fence_array_work);
 
@@ -174,7 +176,10 @@  struct dma_fence_array *dma_fence_array_create(int num_fences,
 	atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
 	array->fences = fences;
 
-	array->base.error = PENDING_ERROR;
+	fence->error = PENDING_ERROR;
+
+	if (signal_on_any)
+		dma_fence_enable_sw_signaling(fence);
 
 	return array;
 }
diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c
index 1b4cb3e5cec9..0518e53880f6 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -152,7 +152,8 @@  static bool dma_fence_chain_enable_signaling(struct dma_fence *fence)
 		struct dma_fence *f = chain ? chain->fence : fence;
 
 		dma_fence_get(f);
-		if (!dma_fence_add_callback(f, &head->cb, dma_fence_chain_cb)) {
+		if (!dma_fence_add_callback_nested(f, &head->cb,
+						   dma_fence_chain_cb)) {
 			dma_fence_put(fence);
 			return true;
 		}
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 066400ed8841..90a3d5121746 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -610,6 +610,37 @@  void dma_fence_enable_sw_signaling(struct dma_fence *fence)
 }
 EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
 
+static int __dma_fence_add_callback(struct dma_fence *fence,
+				    struct dma_fence_cb *cb,
+				    dma_fence_func_t func,
+				    int nest_level)
+{
+	unsigned long flags;
+	int ret = 0;
+
+	if (WARN_ON(!fence || !func))
+		return -EINVAL;
+
+	if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
+		INIT_LIST_HEAD(&cb->node);
+		return -ENOENT;
+	}
+
+	spin_lock_irqsave_nested(fence->lock, flags, 0);
+
+	if (__dma_fence_enable_signaling(fence)) {
+		cb->func = func;
+		list_add_tail(&cb->node, &fence->cb_list);
+	} else {
+		INIT_LIST_HEAD(&cb->node);
+		ret = -ENOENT;
+	}
+
+	spin_unlock_irqrestore(fence->lock, flags);
+
+	return ret;
+}
+
 /**
  * dma_fence_add_callback - add a callback to be called when the fence
  * is signaled
@@ -635,33 +666,33 @@  EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
 int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
 			   dma_fence_func_t func)
 {
-	unsigned long flags;
-	int ret = 0;
-
-	if (WARN_ON(!fence || !func))
-		return -EINVAL;
-
-	if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
-		INIT_LIST_HEAD(&cb->node);
-		return -ENOENT;
-	}
-
-	spin_lock_irqsave(fence->lock, flags);
-
-	if (__dma_fence_enable_signaling(fence)) {
-		cb->func = func;
-		list_add_tail(&cb->node, &fence->cb_list);
-	} else {
-		INIT_LIST_HEAD(&cb->node);
-		ret = -ENOENT;
-	}
-
-	spin_unlock_irqrestore(fence->lock, flags);
-
-	return ret;
+	return __dma_fence_add_callback(fence, cb, func, 0);
 }
 EXPORT_SYMBOL(dma_fence_add_callback);
 
+/**
+ * dma_fence_add_callback_nested - add a callback from within a fence locked
+ * section to be called when the fence is signaled
+ * @fence: the fence to wait on
+ * @cb: the callback to register
+ * @func: the function to call
+ *
+ * This function is identical to dma_fence_add_callback() except it is
+ * intended to be used from within a section where the fence lock of
+ * another fence might be locked, and where it is guaranteed that
+ * other fence will signal _after_ @fence.
+ *
+ * Returns 0 in case of success, -ENOENT if the fence is already signaled
+ * and -EINVAL in case of error.
+ */
+int dma_fence_add_callback_nested(struct dma_fence *fence,
+				  struct dma_fence_cb *cb,
+				  dma_fence_func_t func)
+{
+	return __dma_fence_add_callback(fence, cb, func, SINGLE_DEPTH_NESTING);
+}
+EXPORT_SYMBOL(dma_fence_add_callback_nested);
+
 /**
  * dma_fence_get_status - returns the status upon completion
  * @fence: the dma_fence to query
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 1ea691753bd3..405cd83936f6 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -377,6 +377,9 @@  signed long dma_fence_default_wait(struct dma_fence *fence,
 int dma_fence_add_callback(struct dma_fence *fence,
 			   struct dma_fence_cb *cb,
 			   dma_fence_func_t func);
+int dma_fence_add_callback_nested(struct dma_fence *fence,
+				  struct dma_fence_cb *cb,
+				  dma_fence_func_t func);
 bool dma_fence_remove_callback(struct dma_fence *fence,
 			       struct dma_fence_cb *cb);
 void dma_fence_enable_sw_signaling(struct dma_fence *fence);