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@xxxxxxxxxxxxxxxxxx>
---
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
