[PATCH 3.13 098/120] drm/gem: Always initialize the gem object in object_init

[Greg Kroah-Hartman]

3.13-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Daniel Vetter <daniel.vetter@xxxxxxxx>

commit 6ab11a2635ce988ebc2e798947beb72cf7324119 upstream.

At least drm/i915 expects that the obj->dev pointer is set even in
failure paths. Specifically when the shmem initialization fails we
call i915_gem_object_free which needs to deref obj->base.dev to get at
the slab pointer in the device private structure. And the shmem
allocation can easily fail when userspace is hitting open file limits.

Doing the structure init even when the shmem file allocation fails
prevents this Oops.

This is a regression from

commit 89c8233f82d9c8af5b20e72e4a185a38a7d3c50b
Author: David Herrmann <dh.herrmann@xxxxxxxxx>
Date:   Thu Jul 11 11:56:32 2013 +0200

    drm/gem: simplify object initialization

v2: Add regression note which Chris supplied.

Testcase: igt/gem_fd_exhaustion
Reported-and-Suggested-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
References: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
Reviewed-by: David Herrmann <dh.herrmann@xxxxxxxxx>
Cc: David Herrmann <dh.herrmann@xxxxxxxxx>
Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

---
 drivers/gpu/drm/drm_gem.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -129,11 +129,12 @@ int drm_gem_object_init(struct drm_devic
 {
 	struct file *filp;
 
+	drm_gem_private_object_init(dev, obj, size);
+
 	filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
 	if (IS_ERR(filp))
 		return PTR_ERR(filp);
 
-	drm_gem_private_object_init(dev, obj, size);
 	obj->filp = filp;
 
 	return 0;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/