* [PATCH v1 0/2] Fixes for dma-buf locking issues found by Smatch
@ 2022-10-26 22:46 ` Dmitry Osipenko
0 siblings, 0 replies; 16+ messages in thread
From: Dmitry Osipenko @ 2022-10-26 22:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, Christian König, David Airlie,
Daniel Vetter, noralf, Dan Carpenter
Cc: dri-devel, linux-kernel
Hello,
Here are the two patches fixing minor problems introduced by my
"dma-buf locking convention" series. Thanks to Dan Carpenter who
checked linux-next with Smatch and reported the found issues!
Please review/ack, I'll apply the patches to misc-next afterwards.
Thanks!
Dmitry Osipenko (2):
dma-buf: Make locking consistent in dma_buf_detach()
drm/gem: Check whether object is NULL in drm_gem_vunmap()
drivers/dma-buf/dma-buf.c | 3 ++-
drivers/gpu/drm/drm_gem.c | 9 ++++++---
2 files changed, 8 insertions(+), 4 deletions(-)
--
2.37.3
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()
2022-10-26 22:46 ` Dmitry Osipenko
@ 2022-10-26 22:46 ` Dmitry Osipenko
-1 siblings, 0 replies; 16+ messages in thread
From: Dmitry Osipenko @ 2022-10-26 22:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, Christian König, David Airlie,
Daniel Vetter, noralf, Dan Carpenter
Cc: linux-kernel, dri-devel
The dma_buf_detach() locks attach->dmabuf->resv and then unlocks
dmabuf->resv, which could be a two different locks from a static
code checker perspective. In particular this triggers Smatch to
report the "double unlock" error. Make the locking pointers consistent.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/dri-devel/Y1fLfsccW3AS%2Fo+%2F@kili/
Fixes: 809d9c72c2f8 ("dma-buf: Move dma_buf_attach() to dynamic locking specification")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
drivers/dma-buf/dma-buf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c40d72d318fd..6e33ef4fde34 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -998,9 +998,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
if (WARN_ON(!dmabuf || !attach))
return;
- dma_resv_lock(attach->dmabuf->resv, NULL);
+ dma_resv_lock(dmabuf->resv, NULL);
if (attach->sgt) {
+ WARN_ON(dmabuf != attach->dmabuf);
__unmap_dma_buf(attach, attach->sgt, attach->dir);
--
2.37.3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()
@ 2022-10-26 22:46 ` Dmitry Osipenko
0 siblings, 0 replies; 16+ messages in thread
From: Dmitry Osipenko @ 2022-10-26 22:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, Christian König, David Airlie,
Daniel Vetter, noralf, Dan Carpenter
Cc: dri-devel, linux-kernel
The dma_buf_detach() locks attach->dmabuf->resv and then unlocks
dmabuf->resv, which could be a two different locks from a static
code checker perspective. In particular this triggers Smatch to
report the "double unlock" error. Make the locking pointers consistent.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/dri-devel/Y1fLfsccW3AS%2Fo+%2F@kili/
Fixes: 809d9c72c2f8 ("dma-buf: Move dma_buf_attach() to dynamic locking specification")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
drivers/dma-buf/dma-buf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c40d72d318fd..6e33ef4fde34 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -998,9 +998,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
if (WARN_ON(!dmabuf || !attach))
return;
- dma_resv_lock(attach->dmabuf->resv, NULL);
+ dma_resv_lock(dmabuf->resv, NULL);
if (attach->sgt) {
+ WARN_ON(dmabuf != attach->dmabuf);
__unmap_dma_buf(attach, attach->sgt, attach->dir);
--
2.37.3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()
2022-10-26 22:46 ` Dmitry Osipenko
@ 2022-10-27 6:13 ` Christian König
-1 siblings, 0 replies; 16+ messages in thread
From: Christian König @ 2022-10-27 6:13 UTC (permalink / raw)
To: Dmitry Osipenko, Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, David Airlie, Daniel Vetter, noralf,
Dan Carpenter
Cc: dri-devel, linux-kernel
Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
> The dma_buf_detach() locks attach->dmabuf->resv and then unlocks
> dmabuf->resv, which could be a two different locks from a static
> code checker perspective. In particular this triggers Smatch to
> report the "double unlock" error. Make the locking pointers consistent.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Link: https://lore.kernel.org/dri-devel/Y1fLfsccW3AS%2Fo+%2F@kili/
> Fixes: 809d9c72c2f8 ("dma-buf: Move dma_buf_attach() to dynamic locking specification")
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
It would be even cleaner if we completely drop the dmabuf parameter for
the function and just use the inside the attachment.
Anyway patch is Reviewed-by: Christian König <christian.koenig@amd.com>
for now, wider cleanups can come later on.
Regards,
Christian.
> ---
> drivers/dma-buf/dma-buf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index c40d72d318fd..6e33ef4fde34 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -998,9 +998,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
> if (WARN_ON(!dmabuf || !attach))
> return;
>
> - dma_resv_lock(attach->dmabuf->resv, NULL);
> + dma_resv_lock(dmabuf->resv, NULL);
>
> if (attach->sgt) {
> + WARN_ON(dmabuf != attach->dmabuf);
>
> __unmap_dma_buf(attach, attach->sgt, attach->dir);
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()
@ 2022-10-27 6:13 ` Christian König
0 siblings, 0 replies; 16+ messages in thread
From: Christian König @ 2022-10-27 6:13 UTC (permalink / raw)
To: Dmitry Osipenko, Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, David Airlie, Daniel Vetter, noralf,
Dan Carpenter
Cc: linux-kernel, dri-devel
Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
> The dma_buf_detach() locks attach->dmabuf->resv and then unlocks
> dmabuf->resv, which could be a two different locks from a static
> code checker perspective. In particular this triggers Smatch to
> report the "double unlock" error. Make the locking pointers consistent.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Link: https://lore.kernel.org/dri-devel/Y1fLfsccW3AS%2Fo+%2F@kili/
> Fixes: 809d9c72c2f8 ("dma-buf: Move dma_buf_attach() to dynamic locking specification")
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
It would be even cleaner if we completely drop the dmabuf parameter for
the function and just use the inside the attachment.
Anyway patch is Reviewed-by: Christian König <christian.koenig@amd.com>
for now, wider cleanups can come later on.
Regards,
Christian.
> ---
> drivers/dma-buf/dma-buf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index c40d72d318fd..6e33ef4fde34 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -998,9 +998,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
> if (WARN_ON(!dmabuf || !attach))
> return;
>
> - dma_resv_lock(attach->dmabuf->resv, NULL);
> + dma_resv_lock(dmabuf->resv, NULL);
>
> if (attach->sgt) {
> + WARN_ON(dmabuf != attach->dmabuf);
>
> __unmap_dma_buf(attach, attach->sgt, attach->dir);
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()
2022-10-27 6:13 ` Christian König
@ 2022-10-27 10:34 ` Dmitry Osipenko
-1 siblings, 0 replies; 16+ messages in thread
From: Dmitry Osipenko @ 2022-10-27 10:34 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Sumit Semwal, Thomas Zimmermann, David Airlie, Daniel Vetter,
noralf, Dan Carpenter
Cc: dri-devel, linux-kernel
On 10/27/22 09:13, Christian König wrote:
> Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
>> The dma_buf_detach() locks attach->dmabuf->resv and then unlocks
>> dmabuf->resv, which could be a two different locks from a static
>> code checker perspective. In particular this triggers Smatch to
>> report the "double unlock" error. Make the locking pointers consistent.
>>
>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>> Link: https://lore.kernel.org/dri-devel/Y1fLfsccW3AS%2Fo+%2F@kili/
>> Fixes: 809d9c72c2f8 ("dma-buf: Move dma_buf_attach() to dynamic
>> locking specification")
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>
> It would be even cleaner if we completely drop the dmabuf parameter for
> the function and just use the inside the attachment.
>
> Anyway patch is Reviewed-by: Christian König <christian.koenig@amd.com>
> for now, wider cleanups can come later on.
I had the same thought about dropping the dmabuf parameter.
Looking at this patch again, perhaps a better dmabuf sanity-check will be:
- if (WARN_ON(!dmabuf || !attach))
+ if (WARN_ON(!dmabuf || !attach || dmabuf != attach->dmabuf))
I'll switch to this version in v2, if there are no objections.
>
>> ---
>> drivers/dma-buf/dma-buf.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index c40d72d318fd..6e33ef4fde34 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -998,9 +998,10 @@ void dma_buf_detach(struct dma_buf *dmabuf,
>> struct dma_buf_attachment *attach)
>> if (WARN_ON(!dmabuf || !attach))
>> return;
>> - dma_resv_lock(attach->dmabuf->resv, NULL);
>> + dma_resv_lock(dmabuf->resv, NULL);
>> if (attach->sgt) {
>> + WARN_ON(dmabuf != attach->dmabuf);
>> __unmap_dma_buf(attach, attach->sgt, attach->dir);
>>
>
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()
@ 2022-10-27 10:34 ` Dmitry Osipenko
0 siblings, 0 replies; 16+ messages in thread
From: Dmitry Osipenko @ 2022-10-27 10:34 UTC (permalink / raw)
To: Christian König, Maarten Lankhorst, Maxime Ripard,
Sumit Semwal, Thomas Zimmermann, David Airlie, Daniel Vetter,
noralf, Dan Carpenter
Cc: linux-kernel, dri-devel
On 10/27/22 09:13, Christian König wrote:
> Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
>> The dma_buf_detach() locks attach->dmabuf->resv and then unlocks
>> dmabuf->resv, which could be a two different locks from a static
>> code checker perspective. In particular this triggers Smatch to
>> report the "double unlock" error. Make the locking pointers consistent.
>>
>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>> Link: https://lore.kernel.org/dri-devel/Y1fLfsccW3AS%2Fo+%2F@kili/
>> Fixes: 809d9c72c2f8 ("dma-buf: Move dma_buf_attach() to dynamic
>> locking specification")
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>
> It would be even cleaner if we completely drop the dmabuf parameter for
> the function and just use the inside the attachment.
>
> Anyway patch is Reviewed-by: Christian König <christian.koenig@amd.com>
> for now, wider cleanups can come later on.
I had the same thought about dropping the dmabuf parameter.
Looking at this patch again, perhaps a better dmabuf sanity-check will be:
- if (WARN_ON(!dmabuf || !attach))
+ if (WARN_ON(!dmabuf || !attach || dmabuf != attach->dmabuf))
I'll switch to this version in v2, if there are no objections.
>
>> ---
>> drivers/dma-buf/dma-buf.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index c40d72d318fd..6e33ef4fde34 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -998,9 +998,10 @@ void dma_buf_detach(struct dma_buf *dmabuf,
>> struct dma_buf_attachment *attach)
>> if (WARN_ON(!dmabuf || !attach))
>> return;
>> - dma_resv_lock(attach->dmabuf->resv, NULL);
>> + dma_resv_lock(dmabuf->resv, NULL);
>> if (attach->sgt) {
>> + WARN_ON(dmabuf != attach->dmabuf);
>> __unmap_dma_buf(attach, attach->sgt, attach->dir);
>>
>
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()
2022-10-26 22:46 ` Dmitry Osipenko
@ 2022-10-26 22:46 ` Dmitry Osipenko
-1 siblings, 0 replies; 16+ messages in thread
From: Dmitry Osipenko @ 2022-10-26 22:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, Christian König, David Airlie,
Daniel Vetter, noralf, Dan Carpenter
Cc: linux-kernel, dri-devel
The drm_gem_vunmap() will crash with a NULL dereference if the passed
object pointer is NULL. It wasn't a problem before we added the locking
support to drm_gem_vunmap function because the mapping argument was always
NULL together with the object. Make drm_gem_vunmap() functions to handle
the NULL pointers better.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/
Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
drivers/gpu/drm/drm_gem.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index b8db675e7fb5..ee0a246ff4ac 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap);
void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
{
- dma_resv_assert_held(obj->resv);
-
- if (iosys_map_is_null(map))
+ if (!obj || iosys_map_is_null(map))
return;
+ dma_resv_assert_held(obj->resv);
+
if (obj->funcs->vunmap)
obj->funcs->vunmap(obj, map);
@@ -1202,6 +1202,9 @@ EXPORT_SYMBOL(drm_gem_vmap_unlocked);
void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
{
+ if (!obj || iosys_map_is_null(map))
+ return;
+
dma_resv_lock(obj->resv, NULL);
drm_gem_vunmap(obj, map);
dma_resv_unlock(obj->resv);
--
2.37.3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()
@ 2022-10-26 22:46 ` Dmitry Osipenko
0 siblings, 0 replies; 16+ messages in thread
From: Dmitry Osipenko @ 2022-10-26 22:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, Christian König, David Airlie,
Daniel Vetter, noralf, Dan Carpenter
Cc: dri-devel, linux-kernel
The drm_gem_vunmap() will crash with a NULL dereference if the passed
object pointer is NULL. It wasn't a problem before we added the locking
support to drm_gem_vunmap function because the mapping argument was always
NULL together with the object. Make drm_gem_vunmap() functions to handle
the NULL pointers better.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/
Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
drivers/gpu/drm/drm_gem.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index b8db675e7fb5..ee0a246ff4ac 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap);
void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
{
- dma_resv_assert_held(obj->resv);
-
- if (iosys_map_is_null(map))
+ if (!obj || iosys_map_is_null(map))
return;
+ dma_resv_assert_held(obj->resv);
+
if (obj->funcs->vunmap)
obj->funcs->vunmap(obj, map);
@@ -1202,6 +1202,9 @@ EXPORT_SYMBOL(drm_gem_vmap_unlocked);
void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
{
+ if (!obj || iosys_map_is_null(map))
+ return;
+
dma_resv_lock(obj->resv, NULL);
drm_gem_vunmap(obj, map);
dma_resv_unlock(obj->resv);
--
2.37.3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()
2022-10-26 22:46 ` Dmitry Osipenko
@ 2022-10-27 6:17 ` Christian König
-1 siblings, 0 replies; 16+ messages in thread
From: Christian König @ 2022-10-27 6:17 UTC (permalink / raw)
To: Dmitry Osipenko, Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, David Airlie, Daniel Vetter, noralf,
Dan Carpenter
Cc: dri-devel, linux-kernel
Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
> The drm_gem_vunmap() will crash with a NULL dereference if the passed
> object pointer is NULL. It wasn't a problem before we added the locking
> support to drm_gem_vunmap function because the mapping argument was always
> NULL together with the object. Make drm_gem_vunmap() functions to handle
> the NULL pointers better.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/
> Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations")
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---
> drivers/gpu/drm/drm_gem.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index b8db675e7fb5..ee0a246ff4ac 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap);
>
> void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
> {
> - dma_resv_assert_held(obj->resv);
> -
> - if (iosys_map_is_null(map))
> + if (!obj || iosys_map_is_null(map))
> return;
I'm not very keen about that. Calling a function with all parameters
NULL doesn't make much sense and is clearly a coding error. Hiding that
somehow doesn't help but rather makes things worse.
The only execption to that are things like kfree() or *_put() which work
with the lifetime of objects.
Why is the static checker complaining about that in the first place?
Regards,
Christian.
>
> + dma_resv_assert_held(obj->resv);
> +
> if (obj->funcs->vunmap)
> obj->funcs->vunmap(obj, map);
>
> @@ -1202,6 +1202,9 @@ EXPORT_SYMBOL(drm_gem_vmap_unlocked);
>
> void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
> {
> + if (!obj || iosys_map_is_null(map))
> + return;
> +
> dma_resv_lock(obj->resv, NULL);
> drm_gem_vunmap(obj, map);
> dma_resv_unlock(obj->resv);
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()
@ 2022-10-27 6:17 ` Christian König
0 siblings, 0 replies; 16+ messages in thread
From: Christian König @ 2022-10-27 6:17 UTC (permalink / raw)
To: Dmitry Osipenko, Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, David Airlie, Daniel Vetter, noralf,
Dan Carpenter
Cc: linux-kernel, dri-devel
Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
> The drm_gem_vunmap() will crash with a NULL dereference if the passed
> object pointer is NULL. It wasn't a problem before we added the locking
> support to drm_gem_vunmap function because the mapping argument was always
> NULL together with the object. Make drm_gem_vunmap() functions to handle
> the NULL pointers better.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/
> Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations")
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---
> drivers/gpu/drm/drm_gem.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index b8db675e7fb5..ee0a246ff4ac 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap);
>
> void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
> {
> - dma_resv_assert_held(obj->resv);
> -
> - if (iosys_map_is_null(map))
> + if (!obj || iosys_map_is_null(map))
> return;
I'm not very keen about that. Calling a function with all parameters
NULL doesn't make much sense and is clearly a coding error. Hiding that
somehow doesn't help but rather makes things worse.
The only execption to that are things like kfree() or *_put() which work
with the lifetime of objects.
Why is the static checker complaining about that in the first place?
Regards,
Christian.
>
> + dma_resv_assert_held(obj->resv);
> +
> if (obj->funcs->vunmap)
> obj->funcs->vunmap(obj, map);
>
> @@ -1202,6 +1202,9 @@ EXPORT_SYMBOL(drm_gem_vmap_unlocked);
>
> void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
> {
> + if (!obj || iosys_map_is_null(map))
> + return;
> +
> dma_resv_lock(obj->resv, NULL);
> drm_gem_vunmap(obj, map);
> dma_resv_unlock(obj->resv);
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()
2022-10-27 6:17 ` Christian König
@ 2022-10-27 7:28 ` Dan Carpenter
-1 siblings, 0 replies; 16+ messages in thread
From: Dan Carpenter @ 2022-10-27 7:28 UTC (permalink / raw)
To: Christian König
Cc: Dmitry Osipenko, Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, David Airlie, Daniel Vetter, noralf,
dri-devel, linux-kernel
On Thu, Oct 27, 2022 at 08:17:31AM +0200, Christian König wrote:
>
>
> Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
> > The drm_gem_vunmap() will crash with a NULL dereference if the passed
> > object pointer is NULL. It wasn't a problem before we added the locking
> > support to drm_gem_vunmap function because the mapping argument was always
> > NULL together with the object. Make drm_gem_vunmap() functions to handle
> > the NULL pointers better.
> >
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/ Fixes:
> > 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap
> > operations")
> > Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > ---
> > drivers/gpu/drm/drm_gem.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index b8db675e7fb5..ee0a246ff4ac 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap);
> > void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
> > {
> > - dma_resv_assert_held(obj->resv);
> > -
> > - if (iosys_map_is_null(map))
> > + if (!obj || iosys_map_is_null(map))
> > return;
>
> I'm not very keen about that. Calling a function with all parameters NULL
> doesn't make much sense and is clearly a coding error. Hiding that somehow
> doesn't help but rather makes things worse.
>
> The only execption to that are things like kfree() or *_put() which work
> with the lifetime of objects.
>
> Why is the static checker complaining about that in the first place?
>
drivers/gpu/drm/drm_client.c:240 drm_client_buffer_delete()
warn: variable dereferenced before check 'buffer->gem' (see line 238)
regards,
dan carpenter
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()
@ 2022-10-27 7:28 ` Dan Carpenter
0 siblings, 0 replies; 16+ messages in thread
From: Dan Carpenter @ 2022-10-27 7:28 UTC (permalink / raw)
To: Christian König
Cc: Dmitry Osipenko, linux-kernel, noralf, dri-devel,
Thomas Zimmermann, Sumit Semwal
On Thu, Oct 27, 2022 at 08:17:31AM +0200, Christian König wrote:
>
>
> Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
> > The drm_gem_vunmap() will crash with a NULL dereference if the passed
> > object pointer is NULL. It wasn't a problem before we added the locking
> > support to drm_gem_vunmap function because the mapping argument was always
> > NULL together with the object. Make drm_gem_vunmap() functions to handle
> > the NULL pointers better.
> >
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/ Fixes:
> > 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap
> > operations")
> > Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > ---
> > drivers/gpu/drm/drm_gem.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index b8db675e7fb5..ee0a246ff4ac 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap);
> > void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
> > {
> > - dma_resv_assert_held(obj->resv);
> > -
> > - if (iosys_map_is_null(map))
> > + if (!obj || iosys_map_is_null(map))
> > return;
>
> I'm not very keen about that. Calling a function with all parameters NULL
> doesn't make much sense and is clearly a coding error. Hiding that somehow
> doesn't help but rather makes things worse.
>
> The only execption to that are things like kfree() or *_put() which work
> with the lifetime of objects.
>
> Why is the static checker complaining about that in the first place?
>
drivers/gpu/drm/drm_client.c:240 drm_client_buffer_delete()
warn: variable dereferenced before check 'buffer->gem' (see line 238)
regards,
dan carpenter
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()
2022-10-27 7:28 ` Dan Carpenter
@ 2022-10-27 7:40 ` Christian König
-1 siblings, 0 replies; 16+ messages in thread
From: Christian König @ 2022-10-27 7:40 UTC (permalink / raw)
To: Dan Carpenter
Cc: Dmitry Osipenko, Maarten Lankhorst, Maxime Ripard, Sumit Semwal,
Thomas Zimmermann, David Airlie, Daniel Vetter, noralf,
dri-devel, linux-kernel
Am 27.10.22 um 09:28 schrieb Dan Carpenter:
> On Thu, Oct 27, 2022 at 08:17:31AM +0200, Christian König wrote:
>>
>> Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
>>> The drm_gem_vunmap() will crash with a NULL dereference if the passed
>>> object pointer is NULL. It wasn't a problem before we added the locking
>>> support to drm_gem_vunmap function because the mapping argument was always
>>> NULL together with the object. Make drm_gem_vunmap() functions to handle
>>> the NULL pointers better.
>>>
>>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2FY1kFEGxT8MVlf32V%40kili%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C50d3b7e10eca4c7fb72108dab7ecd646%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638024525139985844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ET0TRHscb1bQVVHgBkmYvTQyV2Q6WqcMC83LDlrY5ZM%3D&reserved=0 Fixes:
>>> 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap
>>> operations")
>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>> ---
>>> drivers/gpu/drm/drm_gem.c | 9 ++++++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>>> index b8db675e7fb5..ee0a246ff4ac 100644
>>> --- a/drivers/gpu/drm/drm_gem.c
>>> +++ b/drivers/gpu/drm/drm_gem.c
>>> @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap);
>>> void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
>>> {
>>> - dma_resv_assert_held(obj->resv);
>>> -
>>> - if (iosys_map_is_null(map))
>>> + if (!obj || iosys_map_is_null(map))
>>> return;
>> I'm not very keen about that. Calling a function with all parameters NULL
>> doesn't make much sense and is clearly a coding error. Hiding that somehow
>> doesn't help but rather makes things worse.
>>
>> The only execption to that are things like kfree() or *_put() which work
>> with the lifetime of objects.
>>
>> Why is the static checker complaining about that in the first place?
>>
> drivers/gpu/drm/drm_client.c:240 drm_client_buffer_delete()
> warn: variable dereferenced before check 'buffer->gem' (see line 238)
Well than rather modify drm_client_buffer_delete() instead.
Calling drm_gem_vunmap() with obj NULL is certainly not a good idea if
we even check that for drm_gem_object_put().
Interesting that the static checkers complain about that :)
Regards,
Christian.
>
> regards,
> dan carpenter
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()
@ 2022-10-27 7:40 ` Christian König
0 siblings, 0 replies; 16+ messages in thread
From: Christian König @ 2022-10-27 7:40 UTC (permalink / raw)
To: Dan Carpenter
Cc: Dmitry Osipenko, linux-kernel, noralf, dri-devel,
Thomas Zimmermann, Sumit Semwal
Am 27.10.22 um 09:28 schrieb Dan Carpenter:
> On Thu, Oct 27, 2022 at 08:17:31AM +0200, Christian König wrote:
>>
>> Am 27.10.22 um 00:46 schrieb Dmitry Osipenko:
>>> The drm_gem_vunmap() will crash with a NULL dereference if the passed
>>> object pointer is NULL. It wasn't a problem before we added the locking
>>> support to drm_gem_vunmap function because the mapping argument was always
>>> NULL together with the object. Make drm_gem_vunmap() functions to handle
>>> the NULL pointers better.
>>>
>>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2FY1kFEGxT8MVlf32V%40kili%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C50d3b7e10eca4c7fb72108dab7ecd646%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638024525139985844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ET0TRHscb1bQVVHgBkmYvTQyV2Q6WqcMC83LDlrY5ZM%3D&reserved=0 Fixes:
>>> 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap
>>> operations")
>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>> ---
>>> drivers/gpu/drm/drm_gem.c | 9 ++++++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>>> index b8db675e7fb5..ee0a246ff4ac 100644
>>> --- a/drivers/gpu/drm/drm_gem.c
>>> +++ b/drivers/gpu/drm/drm_gem.c
>>> @@ -1175,11 +1175,11 @@ EXPORT_SYMBOL(drm_gem_vmap);
>>> void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
>>> {
>>> - dma_resv_assert_held(obj->resv);
>>> -
>>> - if (iosys_map_is_null(map))
>>> + if (!obj || iosys_map_is_null(map))
>>> return;
>> I'm not very keen about that. Calling a function with all parameters NULL
>> doesn't make much sense and is clearly a coding error. Hiding that somehow
>> doesn't help but rather makes things worse.
>>
>> The only execption to that are things like kfree() or *_put() which work
>> with the lifetime of objects.
>>
>> Why is the static checker complaining about that in the first place?
>>
> drivers/gpu/drm/drm_client.c:240 drm_client_buffer_delete()
> warn: variable dereferenced before check 'buffer->gem' (see line 238)
Well than rather modify drm_client_buffer_delete() instead.
Calling drm_gem_vunmap() with obj NULL is certainly not a good idea if
we even check that for drm_gem_object_put().
Interesting that the static checkers complain about that :)
Regards,
Christian.
>
> regards,
> dan carpenter
>
^ permalink raw reply [flat|nested] 16+ messages in thread