lkml.org 
[lkml]   [2018]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available
From
Date
Well, not really.

It's just that reservation_object_reserve_shared() is called multiple
times without actually adding fences.

That is a perfectly normal use case, so nothing special here.

Christian.

Am 05.03.2018 um 12:47 schrieb Liu, Monk:
> Can you give more details ? thanks
>
> /Monk
>
> -----Original Message-----
> From: Koenig, Christian
> Sent: 2018年3月5日 19:39
> 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 05.03.2018 um 12:37 schrieb Liu, Monk:
>> But the thing confuse me is according to the design, if driver keep
>> calling reserve_shared() prior to add_fence(), and with lock held of cause, That BUG() shouldn't hit, so there are two things in face looks weired to me:
>> 1) by design in reserve_shared(), obj->staged should be already NULL,
>> so why we kfree on it
> No, that is not correct.
>
>> 2) in fact, amdgpu can hit the case that obj->staged is not NULL in
>> reserved_shared(), don't know how it lead here
> We reserved a fence slot without using it, so it is still there when
> reserve_shared() is called.
>
> Christian.
>
>>
>> Any thought ?
>>
>> /Monk
>>
>> -----Original Message-----
>> From: Koenig, Christian
>> Sent: 2018年3月5日 19:29
>> 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 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

\
 
 \ /
  Last update: 2018-03-05 12:52    [W:0.041 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site