| Message ID | 1519800242-2442-1-git-send-email-Monk.Liu@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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;
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 ? 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;
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
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()... 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
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
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 2) in fact, amdgpu can hit the case that obj->staged is not NULL in reserved_shared(), don't know how it lead here 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
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
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
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
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;
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... 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(-)