[Intel-gfx] [PATCH 04/10] dma-buf: Report signaled links inside dma-fence-chain

Lionel Landwerlin lionel.g.landwerlin at intel.com
Thu Apr 9 11:16:48 UTC 2020


On 09/04/2020 13:52, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2020-04-08 21:00:59)
>> On 03/04/2020 12:12, Chris Wilson wrote:
>>> Whenever we walk along the dma-fence-chain, we prune signaled links to
>>> keep the chain nice and tidy. This leads to situations where we can
>>> prune a link and report the earlier fence as the target seqno --
>>> violating our own consistency checks that the seqno is not more advanced
>>> than the last element in a dma-fence-chain.
>>>
>>> Report a NULL fence and success if the seqno has already been signaled.
>>>
>>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>>> ---
>>>    drivers/dma-buf/dma-fence-chain.c | 7 +++++++
>>>    1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c
>>> index 3d123502ff12..c435bbba851c 100644
>>> --- a/drivers/dma-buf/dma-fence-chain.c
>>> +++ b/drivers/dma-buf/dma-fence-chain.c
>>> @@ -99,6 +99,12 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno)
>>>                return -EINVAL;
>>>    
>>>        dma_fence_chain_for_each(*pfence, &chain->base) {
>>> +             if ((*pfence)->seqno < seqno) { /* already signaled */
>>> +                     dma_fence_put(*pfence);
>>> +                     *pfence = NULL;
>>> +                     break;
>>> +             }
>>> +
>>
>> Wouldn't this condition been fulfilled in the previous check? :
>>
>>
>> chain = to_dma_fence_chain(*pfence);
>> if (!chain || chain->base.seqno < seqno)
>>           return -EINVAL;
> The problem is in the chain iteration. It assumes that an unordered set
> of fences is in the order of the user's seqno. There are no restrictions
> placed on the chain, so we must apply the ordering from the timeline seqno
> directly.
> -Chris


I don't really understand that. chain->seqno should be ordered because 
chain->prev_seqno <= chain->seqno.

Do you have an example where this is not the case?


-Lionel



More information about the Intel-gfx mailing list