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

Chris Wilson chris at chris-wilson.co.uk
Thu Apr 9 13:46:06 UTC 2020


Quoting Lionel Landwerlin (2020-04-09 12:16:48)
> 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?

See the failing test case.
-Chris


More information about the Intel-gfx mailing list