[PATCH v1 0/2] Fixes for dma-buf locking issues found by Smatch

[PATCH v1 0/2] Fixes for dma-buf locking issues found by Smatch

[Dmitry Osipenko]

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

[PATCH v1 0/2] Fixes for dma-buf locking issues found by Smatch

[Dmitry Osipenko]

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

[PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()

[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>
---
 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

[PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()

[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>
---
 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

[PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()

[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;
 
+	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

[PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()

[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;
 
+	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

Re: [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()

[Christian König]

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);
>   

Re: [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()

[Christian König]

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);
>   

Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()

[Christian König]

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);

Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()

[Christian König]

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);

Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()

[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://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

Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()

[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://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

Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()

[Christian König]

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&amp;data=05%7C01%7Cchristian.koenig%40amd.com%7C50d3b7e10eca4c7fb72108dab7ecd646%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638024525139985844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ET0TRHscb1bQVVHgBkmYvTQyV2Q6WqcMC83LDlrY5ZM%3D&amp;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
>

Re: [PATCH v1 2/2] drm/gem: Check whether object is NULL in drm_gem_vunmap()

[Christian König]

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&amp;data=05%7C01%7Cchristian.koenig%40amd.com%7C50d3b7e10eca4c7fb72108dab7ecd646%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638024525139985844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ET0TRHscb1bQVVHgBkmYvTQyV2Q6WqcMC83LDlrY5ZM%3D&amp;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
>

Re: [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()

[Dmitry Osipenko]

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

Re: [PATCH v1 1/2] dma-buf: Make locking consistent in dma_buf_detach()

[Dmitry Osipenko]

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