Fix a couple of dri drivers memory leaks
Subsystems (4)
cover Fix a couple of dri drivers memory leaks
From: Oleg Drokin <[email protected]>
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(-)
Signature · 1 line
2.1.0
PATCH 1/2 drm/qlx: Fix a memory leak on error path
From: Oleg Drokin <[email protected]>
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.
--- drivers/gpu/drm/qxl/qxl_fb.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/gpu/drm/qxl/qxl_fb.c +5 -2
@@ -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; }
Signature · 1 line
2.1.0
PATCH 2/2 drm: fix a memleak on mutex failure path
In reply to [email protected]From: Oleg Drokin <[email protected]>
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.
--- drivers/gpu/drm/drm_modeset_lock.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/drm_modeset_lock.c +3 -1
@@ -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); }
Signature · 1 line
2.1.0
Re: [PATCH 2/2] drm: fix a memleak on mutex failure path
Quoted 5 lines · On Sun, 26 Apr 2015, [email protected] wrote:
From: Oleg Drokin <[email protected]>
Need to free just allocated ctx allocation if we cannot get our config mutex.
Quoted 8 lines
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.htmlFound with smatch.
Signed-off-by Oleg Drokin <[email protected]>CC Daniel Vetter <[email protected]>
The function has another leaking failure path, would be nice to have that fixed too. Maybe with a common out label.
BR,
Jani.
Quoted 27 lines
--- drivers/gpu/drm/drm_modeset_lock.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)drivers/gpu/drm/drm_modeset_lock.c +3
-1@@ -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); }Signature · 6 lines
2.1.0 _______________________________________________ dri-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dri-devel
Signature · 1 line
Jani Nikula, Intel Open Source Technology Center
Re: [PATCH 2/2] drm: fix a memleak on mutex failure path
Hello!
Quoted 10 lines · Jani Nikula
Quoted 9 lines · On Sun, 26 Apr 2015, [email protected] wrote:
From: Oleg Drokin <[email protected]>
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
Quoted 7 lines
Quoted 4 lines
Found with smatch.
Signed-off-by Oleg Drokin <[email protected]>CC Daniel Vetter <[email protected]>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