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(-)
--
2.1.0
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.
Signed-off-by: Oleg Drokin <[email protected]>
---
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
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.
Signed-off-by: Oleg Drokin <[email protected]>
CC: Daniel Vetter <[email protected]>
---
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
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
>
> 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.
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
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
Hello!
On Apr 27, 2015, at 4:56 AM, Jani Nikula wrote:
> 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
>>
>> 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