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(-)
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 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;
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;
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;
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;
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:
- by design in reserve_shared(), obj->staged should be already NULL, so why we kfree on it
No, that is not correct.
- 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:
- by design in reserve_shared(), obj->staged should be already NULL,
so why we kfree on it
No, that is not correct.
- 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:
- by design in reserve_shared(), obj->staged should be already NULL,
so why we kfree on it
No, that is not correct.
- 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
dri-devel@lists.freedesktop.org
-
Christian König -
Christian König -
Liu, Monk -
Monk Liu