[PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

[Christian König]

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 at gmail.com]
> Sent: 2018年3月5日 19:22
> To: Liu, Monk <Monk.Liu at amd.com>; Koenig, Christian <Christian.Koenig at amd.com>; dri-devel at lists.freedesktop.org; linux-kernel at 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 at gmail.com]
>> Sent: 2018年2月28日 16:27
>> To: Liu, Monk <Monk.Liu at amd.com>; dri-devel at lists.freedesktop.org;
>> linux-kernel at 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 at 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel