[PATCH] dma-buf/reservation: should keep later one in add fence(v2)

[Liu, Monk]

okay

________________________________
From: Chris Wilson <chris at chris-wilson.co.uk>
Sent: Tuesday, March 6, 2018 4:24:21 PM
To: Liu, Monk; dri-devel at freedesktop.org
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 at amd.com>
> ---
>  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180306/c7a26aba/attachment.html>