[PATCH] dma-buf: Take a breath during dma-fence-chain subtests

[Christian König]

On 08.07.25 10:56, Janusz Krzysztofik wrote:
>>
>> There is no reason to test enabling signaling each of the element in a loop. So there should be something like 4096 calls to the dma_fence_chain_cb function each jumping to the next unsignaled fence and re-installing the callback.
> 
> So how building a chain should look like in real use cases?  When a user 
> builds a chained link of her fence with another fence then may she enable 
> signaling on the new chain link?  If that other fence occurs a chain link then 
> who should take care of disabling signaling on it so signaling is enabled only 
> on the last link of the chain, not leading to a situation similar to what we 
> have now in the test case?  IOW, what's a correct use pattern of 
> dma_fence_chain?  I can't find that documented anywhere, neither in inline 
> docs nor in commit descriptions.

The dma_fence_chain container is basically a single linked list which allows to "chain" together multiple dma_fence objects.

The use cases is to keep only a single fence even when multiple asynchronous operations have been started.

So you usually keep only the most recently created dma_fence_chain and eventually ask that one to signal when you need to wait for all fences inside the container.

The tricky part is that since the chain can get very long the implementation can't use recursion or otherwise we would potentially overflow the kernel stack. And that needs to be tested and made sure we don't accidentally break the implementation somehow.

Keeping all elements of a dma_fence_chain in an array and asking all of them to signal individually makes no sense, for this use case we have the dma_fence_array in the first place.

Regards,
Christian.

> 
> Thanks,
> Janusz