[PATCH 0/2] Fix a couple of dri drivers memory leaks

[PATCH 0/2] Fix a couple of dri drivers memory leaks

[green]

From: Oleg Drokin <green@linuxhacker.ru>

A couple of memory leaks found by smatch.

Oleg Drokin (2):
  drm/qlx: Fix a memory leak on error path
  drm: fix a memleak on mutex failure path

 drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
 drivers/gpu/drm/qxl/qxl_fb.c       | 7 +++++--
 2 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.1.0

[PATCH 0/2] Fix a couple of dri drivers memory leaks

[green]

From: Oleg Drokin <green@linuxhacker.ru>

A couple of memory leaks found by smatch.

Oleg Drokin (2):
  drm/qlx: Fix a memory leak on error path
  drm: fix a memleak on mutex failure path

 drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
 drivers/gpu/drm/qxl/qxl_fb.c       | 7 +++++--
 2 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.1.0

[PATCH 0/2] Fix a couple of dri drivers memory leaks

[green]

From: Oleg Drokin <green@linuxhacker.ru>

A couple of memory leaks found by smatch.

Oleg Drokin (2):
  drm/qlx: Fix a memory leak on error path
  drm: fix a memleak on mutex failure path

 drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
 drivers/gpu/drm/qxl/qxl_fb.c       | 7 +++++--
 2 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.1.0

[PATCH 1/2] drm/qlx: Fix a memory leak on error path

[green]

From: Oleg Drokin <green@linuxhacker.ru>

shadow allocation could be leaked if framebuffer allocation failed,
so need to free it.
Also added handling for shadow allocation failure itself instead
of causing a crash.

Found with smatch.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
---
 drivers/gpu/drm/qxl/qxl_fb.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index f778c0e..2a88eae 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -526,8 +526,10 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
 		 mode_cmd.height, mode_cmd.pitches[0]);
 
 	shadow = vmalloc(mode_cmd.pitches[0] * mode_cmd.height);
-	/* TODO: what's the usual response to memory allocation errors? */
-	BUG_ON(!shadow);
+	if (!shadow) {
+		ret = -ENOMEM;
+		goto out_unref;
+	}
 	QXL_INFO(qdev,
 	"surface0 at gpu offset %lld, mmap_offset %lld (virt %p, shadow %p)\n",
 		 qxl_bo_gpu_offset(qbo),
@@ -538,6 +540,7 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
 
 	info = framebuffer_alloc(0, device);
 	if (info == NULL) {
+		vfree(shadow);
 		ret = -ENOMEM;
 		goto out_unref;
 	}
-- 
2.1.0

[PATCH 1/2] drm/qlx: Fix a memory leak on error path

[green]

From: Oleg Drokin <green@linuxhacker.ru>

shadow allocation could be leaked if framebuffer allocation failed,
so need to free it.
Also added handling for shadow allocation failure itself instead
of causing a crash.

Found with smatch.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
---
 drivers/gpu/drm/qxl/qxl_fb.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index f778c0e..2a88eae 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -526,8 +526,10 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
 		 mode_cmd.height, mode_cmd.pitches[0]);
 
 	shadow = vmalloc(mode_cmd.pitches[0] * mode_cmd.height);
-	/* TODO: what's the usual response to memory allocation errors? */
-	BUG_ON(!shadow);
+	if (!shadow) {
+		ret = -ENOMEM;
+		goto out_unref;
+	}
 	QXL_INFO(qdev,
 	"surface0 at gpu offset %lld, mmap_offset %lld (virt %p, shadow %p)\n",
 		 qxl_bo_gpu_offset(qbo),
@@ -538,6 +540,7 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
 
 	info = framebuffer_alloc(0, device);
 	if (info = NULL) {
+		vfree(shadow);
 		ret = -ENOMEM;
 		goto out_unref;
 	}
-- 
2.1.0

[PATCH 1/2] drm/qlx: Fix a memory leak on error path

[green]

From: Oleg Drokin <green@linuxhacker.ru>

shadow allocation could be leaked if framebuffer allocation failed,
so need to free it.
Also added handling for shadow allocation failure itself instead
of causing a crash.

Found with smatch.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
---
 drivers/gpu/drm/qxl/qxl_fb.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index f778c0e..2a88eae 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -526,8 +526,10 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
 		 mode_cmd.height, mode_cmd.pitches[0]);
 
 	shadow = vmalloc(mode_cmd.pitches[0] * mode_cmd.height);
-	/* TODO: what's the usual response to memory allocation errors? */
-	BUG_ON(!shadow);
+	if (!shadow) {
+		ret = -ENOMEM;
+		goto out_unref;
+	}
 	QXL_INFO(qdev,
 	"surface0 at gpu offset %lld, mmap_offset %lld (virt %p, shadow %p)\n",
 		 qxl_bo_gpu_offset(qbo),
@@ -538,6 +540,7 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
 
 	info = framebuffer_alloc(0, device);
 	if (info == NULL) {
+		vfree(shadow);
 		ret = -ENOMEM;
 		goto out_unref;
 	}
-- 
2.1.0

[PATCH 2/2] drm: fix a memleak on mutex failure path

[green]

From: Oleg Drokin <green@linuxhacker.ru>

Need to free just allocated ctx allocation if we cannot
get our config mutex.

This one has been flagged by kbuild bot all the way back in August,
but somehow nobody picked it up:
https://lists.01.org/pipermail/kbuild/2014-August/001691.html

Found with smatch.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c
index 51cc47d..1e8c52f 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -80,8 +80,10 @@ int __drm_modeset_lock_all(struct drm_device *dev,
 		return -ENOMEM;
 
 	if (trylock) {
-		if (!mutex_trylock(&config->mutex))
+		if (!mutex_trylock(&config->mutex)) {
+			kfree(ctx);
 			return -EBUSY;
+		}
 	} else {
 		mutex_lock(&config->mutex);
 	}
-- 
2.1.0

[PATCH 2/2] drm: fix a memleak on mutex failure path

[green]

From: Oleg Drokin <green@linuxhacker.ru>

Need to free just allocated ctx allocation if we cannot
get our config mutex.

This one has been flagged by kbuild bot all the way back in August,
but somehow nobody picked it up:
https://lists.01.org/pipermail/kbuild/2014-August/001691.html

Found with smatch.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c
index 51cc47d..1e8c52f 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -80,8 +80,10 @@ int __drm_modeset_lock_all(struct drm_device *dev,
 		return -ENOMEM;
 
 	if (trylock) {
-		if (!mutex_trylock(&config->mutex))
+		if (!mutex_trylock(&config->mutex)) {
+			kfree(ctx);
 			return -EBUSY;
+		}
 	} else {
 		mutex_lock(&config->mutex);
 	}
-- 
2.1.0

[PATCH 2/2] drm: fix a memleak on mutex failure path

[green]

From: Oleg Drokin <green@linuxhacker.ru>

Need to free just allocated ctx allocation if we cannot
get our config mutex.

This one has been flagged by kbuild bot all the way back in August,
but somehow nobody picked it up:
https://lists.01.org/pipermail/kbuild/2014-August/001691.html

Found with smatch.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c
index 51cc47d..1e8c52f 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -80,8 +80,10 @@ int __drm_modeset_lock_all(struct drm_device *dev,
 		return -ENOMEM;
 
 	if (trylock) {
-		if (!mutex_trylock(&config->mutex))
+		if (!mutex_trylock(&config->mutex)) {
+			kfree(ctx);
 			return -EBUSY;
+		}
 	} else {
 		mutex_lock(&config->mutex);
 	}
-- 
2.1.0

Re: [PATCH 2/2] drm: fix a memleak on mutex failure path

[Jani Nikula]

On Sun, 26 Apr 2015, green@linuxhacker.ru wrote:
> From: Oleg Drokin <green@linuxhacker.ru>
>
> Need to free just allocated ctx allocation if we cannot
> get our config mutex.
>
> This one has been flagged by kbuild bot all the way back in August,
> but somehow nobody picked it up:
> https://lists.01.org/pipermail/kbuild/2014-August/001691.html
>
> Found with smatch.
>
> Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
> CC: Daniel Vetter <daniel.vetter@ffwll.ch>

The function has another leaking failure path, would be nice to have
that fixed too. Maybe with a common out label.

BR,
Jani.



> ---
>  drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c
> index 51cc47d..1e8c52f 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -80,8 +80,10 @@ int __drm_modeset_lock_all(struct drm_device *dev,
>  		return -ENOMEM;
>  
>  	if (trylock) {
> -		if (!mutex_trylock(&config->mutex))
> +		if (!mutex_trylock(&config->mutex)) {
> +			kfree(ctx);
>  			return -EBUSY;
> +		}
>  	} else {
>  		mutex_lock(&config->mutex);
>  	}
> -- 
> 2.1.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 2/2] drm: fix a memleak on mutex failure path

[Jani Nikula]

On Sun, 26 Apr 2015, green@linuxhacker.ru wrote:
> From: Oleg Drokin <green@linuxhacker.ru>
>
> Need to free just allocated ctx allocation if we cannot
> get our config mutex.
>
> This one has been flagged by kbuild bot all the way back in August,
> but somehow nobody picked it up:
> https://lists.01.org/pipermail/kbuild/2014-August/001691.html
>
> Found with smatch.
>
> Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
> CC: Daniel Vetter <daniel.vetter@ffwll.ch>

The function has another leaking failure path, would be nice to have
that fixed too. Maybe with a common out label.

BR,
Jani.



> ---
>  drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c
> index 51cc47d..1e8c52f 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -80,8 +80,10 @@ int __drm_modeset_lock_all(struct drm_device *dev,
>  		return -ENOMEM;
>  
>  	if (trylock) {
> -		if (!mutex_trylock(&config->mutex))
> +		if (!mutex_trylock(&config->mutex)) {
> +			kfree(ctx);
>  			return -EBUSY;
> +		}
>  	} else {
>  		mutex_lock(&config->mutex);
>  	}
> -- 
> 2.1.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 2/2] drm: fix a memleak on mutex failure path

[Jani Nikula]

On Sun, 26 Apr 2015, green@linuxhacker.ru wrote:
> From: Oleg Drokin <green@linuxhacker.ru>
>
> Need to free just allocated ctx allocation if we cannot
> get our config mutex.
>
> This one has been flagged by kbuild bot all the way back in August,
> but somehow nobody picked it up:
> https://lists.01.org/pipermail/kbuild/2014-August/001691.html
>
> Found with smatch.
>
> Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
> CC: Daniel Vetter <daniel.vetter@ffwll.ch>

The function has another leaking failure path, would be nice to have
that fixed too. Maybe with a common out label.

BR,
Jani.



> ---
>  drivers/gpu/drm/drm_modeset_lock.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c
> index 51cc47d..1e8c52f 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -80,8 +80,10 @@ int __drm_modeset_lock_all(struct drm_device *dev,
>  		return -ENOMEM;
>  
>  	if (trylock) {
> -		if (!mutex_trylock(&config->mutex))
> +		if (!mutex_trylock(&config->mutex)) {
> +			kfree(ctx);
>  			return -EBUSY;
> +		}
>  	} else {
>  		mutex_lock(&config->mutex);
>  	}
> -- 
> 2.1.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 2/2] drm: fix a memleak on mutex failure path

[Oleg Drokin]

Hello!

On Apr 27, 2015, at 4:56 AM, Jani Nikula wrote:

> On Sun, 26 Apr 2015, green@linuxhacker.ru wrote:
>> From: Oleg Drokin <green@linuxhacker.ru>
>> 
>> Need to free just allocated ctx allocation if we cannot
>> get our config mutex.
>> 
>> This one has been flagged by kbuild bot all the way back in August,
>> but somehow nobody picked it up:
>> https://lists.01.org/pipermail/kbuild/2014-August/001691.html
>> 
>> Found with smatch.
>> 
>> Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
>> CC: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> The function has another leaking failure path, would be nice to have
> that fixed too. Maybe with a common out label.

Hm, you are right, there's another path, though it's less obvious since
what is done with ctx inside of those other calls, but apparently nothing
if there is an error, so it's also a leak.

I'll do an updated patch in a moment.

Bye,
    Oleg

Re: [PATCH 2/2] drm: fix a memleak on mutex failure path

[Oleg Drokin]

Hello!

On Apr 27, 2015, at 4:56 AM, Jani Nikula wrote:

> On Sun, 26 Apr 2015, green@linuxhacker.ru wrote:
>> From: Oleg Drokin <green@linuxhacker.ru>
>> 
>> Need to free just allocated ctx allocation if we cannot
>> get our config mutex.
>> 
>> This one has been flagged by kbuild bot all the way back in August,
>> but somehow nobody picked it up:
>> https://lists.01.org/pipermail/kbuild/2014-August/001691.html
>> 
>> Found with smatch.
>> 
>> Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
>> CC: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> The function has another leaking failure path, would be nice to have
> that fixed too. Maybe with a common out label.

Hm, you are right, there's another path, though it's less obvious since
what is done with ctx inside of those other calls, but apparently nothing
if there is an error, so it's also a leak.

I'll do an updated patch in a moment.

Bye,
    Oleg