Messages in this thread | | | Subject | Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available | From | Christian König <> | Date | Mon, 5 Mar 2018 12:28:31 +0100 |
| |
Am 05.03.2018 um 12:25 schrieb Liu, Monk: > And by the way, I add "if (staged!=NULL) BUG();" prior to "kfree(obj->staged)" in reserve_shared() routine, and this BUG() is actually hit, > The stack dump shows it is hit during the vm_bo_update() in gem_va_update()...
That is expected. The staged handling just makes sure that there is room available, it doesn't guarantee that it is actually used.
E.g. we can end up reserving a fence slot, but then find that we actually don't need it.
Christian.
> > Besides, the whole reservation logic still looks a little weired to me ... especially this staged part ... > > Thanks > > /Monk > > -----Original Message----- > From: Christian König [mailto:ckoenig.leichtzumerken@gmail.com] > Sent: 2018年3月5日 19:22 > To: Liu, Monk <Monk.Liu@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available > > Am 05.03.2018 um 08:55 schrieb Liu, Monk: >> Hi Christian >> >> You are right on that part of obj-staged is set to NULL in add_fence, >> So my following question will be why we kfree(obj->staged) in reserve_shared() if staged is always NULL in that point ? > Good question, I haven't wrote code that so I can't fully answer. > > Maybe Chris or Maarten know more about that. > > Christian. > >> Thanks >> /Monk >> >> -----Original Message----- >> From: Christian König [mailto:ckoenig.leichtzumerken@gmail.com] >> Sent: 2018年2月28日 16:27 >> To: Liu, Monk <Monk.Liu@amd.com>; dri-devel@lists.freedesktop.org; >> linux-kernel@vger.kernel.org >> Subject: Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when >> slot available >> >> Am 28.02.2018 um 07:44 schrieb Monk Liu: >>> under below scenario the obj->fence would refer to a wild pointer: >>> >>> 1,call reservation_object_reserved_shared >>> 2,call reservation_object_add_shared_fence >>> 3,call reservation_object_reserved_shared >>> 4,call reservation_object_add_shared_fence >>> >>> in step 1, staged is allocated, >>> >>> in step 2, code path will go reservation_object_add_shared_replace() >>> and obj->fence would be assigned as staged (through RCU_INIT_POINTER) >>> >>> in step 3, obj->staged will be freed(by simple kfree), which make >>> obj->fence point to a wild pointer... >> Well that explanation is still nonsense. See >> reservation_object_add_shared_fence: >>> obj->staged = NULL; >> Among the first things reservation_object_add_shared_fence() does is >> it sets obj->staged to NULL. >> >> So step 3 will not free anything and we never have a wild pointer. >> >> Regards, >> Christian. >> >>> in step 4, code path will go reservation_object_add_shared_inplace() >>> and inside it the @fobj (which equals to @obj->staged, set by above >>> steps) is already a wild pointer >>> >>> should remov the kfree on staged in >>> reservation_object_reserve_shared() >>> >>> Change-Id: If7c01f1b4be3d3d8a81efa90216841f79ab1fc1c >>> Signed-off-by: Monk Liu <Monk.Liu@amd.com> >>> --- >>> drivers/dma-buf/reservation.c | 7 ++----- >>> 1 file changed, 2 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/dma-buf/reservation.c >>> b/drivers/dma-buf/reservation.c index 375de41..b473ccc 100644 >>> --- a/drivers/dma-buf/reservation.c >>> +++ b/drivers/dma-buf/reservation.c >>> @@ -74,12 +74,9 @@ int reservation_object_reserve_shared(struct reservation_object *obj) >>> old = reservation_object_get_list(obj); >>> >>> if (old && old->shared_max) { >>> - if (old->shared_count < old->shared_max) { >>> - /* perform an in-place update */ >>> - kfree(obj->staged); >>> - obj->staged = NULL; >>> + if (old->shared_count < old->shared_max) >>> return 0; >>> - } else >>> + else >>> max = old->shared_max * 2; >>> } else >>> max = 4; >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
| |