aboutsummaryrefslogtreecommitdiff
path: root/drivers/mfd
diff options
context:
space:
mode:
authorThomas White <taw@bitwiz.org.uk>2009-11-09 22:01:52 +0100
committerThomas White <taw@bitwiz.org.uk>2009-11-09 22:01:52 +0100
commitc848d00bd43c47e7f11724330380e0c68ec7ae5e (patch)
treecd821f44a9300fc81c397e239999e01cd8dbb32b /drivers/mfd
parentcbd833973d74a12c6f07ed5174bf0e1b0f365da2 (diff)
Fix oops in GEM object allocation
If the allocation of a new GEM object failed due to there being no available VRAM, then glamo_gem_object_alloc() would bail out, calling drm_gem_object_unreference() in the process. glamodrm_gem_free_object() would then proceed to try to give back the memory which was unsuccessfully allocated. This obviously doesn't work, and resulted in an oops. To fix it, check that the VRAM block handle is non-NULL before freeing it. Signed-off-by: Thomas White <taw@bitwiz.org.uk>
Diffstat (limited to 'drivers/mfd')
-rw-r--r--drivers/mfd/glamo/glamo-buffer.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/drivers/mfd/glamo/glamo-buffer.c b/drivers/mfd/glamo/glamo-buffer.c
index e1c973c66af..a6d085f3303 100644
--- a/drivers/mfd/glamo/glamo-buffer.c
+++ b/drivers/mfd/glamo/glamo-buffer.c
@@ -319,7 +319,9 @@ void glamodrm_gem_free_object(struct drm_gem_object *obj)
gobj = obj->driver_private;
/* Free the VRAM */
- drm_mm_put_block(gobj->block);
+ if ( gobj->block != NULL ) {
+ drm_mm_put_block(gobj->block);
+ }
/* Release mappings */
list = &obj->map_list;