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(-)
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; }
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); }
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
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
dri-devel@lists.freedesktop.org