|
okay From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 6, 2018 4:24:21 PM To: Liu, Monk; dri-devel@xxxxxxxxxxxxxxx Cc: Liu, Monk Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2) Quoting Monk Liu (2018-03-06 03:53:10)
> v2: > still check context first to avoid warning from dma_fence_is_later > apply this fix in add_shared_replace as well > > Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767 > Signed-off-by: Monk Liu <Monk.Liu@xxxxxxx> > --- > drivers/dma-buf/reservation.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c > index 314eb10..c6e3c86 100644 > --- a/drivers/dma-buf/reservation.c > +++ b/drivers/dma-buf/reservation.c > @@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct reservation_object *obj, > old_fence = rcu_dereference_protected(fobj->shared[i], > reservation_object_held(obj)); > > - if (old_fence->context == fence->context) { > + if (old_fence->context == fence->context && > + dma_fence_is_later(fence, old_fence)) { This should be true by construction. Adding an older fence on the same context is a programming bug, imo. Between different callers the resv should have been locked and the fenced operations serialised, from the same caller, you shouldn't be handling more than one output fence? -Chris |
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
