[Intel-gfx] [PATCH] drm/i915: Unreference object, not handle
Eric Anholt
eric at anholt.net
Wed May 27 21:34:59 CEST 2009
On Wed, 2009-05-27 at 17:36 +0200, Jonas Bonn wrote:
> The newly created handle should not be unreferenced here, just the object
> that the handle points to.
>
> Signed-off-by: Jonas Bonn <jonas at southpole.se>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 717b6a8..97a17a8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -123,7 +123,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
> 0
> ret = drm_gem_handle_create(file_priv, obj, &handle);
> mutex_lock(&dev->struct_mutex);
> - drm_gem_object_handle_unreference(obj);
> + drm_gem_object_unreference(obj);
> mutex_unlock(&dev->struct_mutex);
>
> if (ret)
Getting out of i915_gem_create_ioctl, there should be one reference to
the handle, and one reference to the object due to that handle, right?
From my reading:
drm_gem_object_alloc() returns with
obj_refcount = 1 (kref_init)
handle_refcount = 1 (kref_init)
drm_gem_handle_create then does:
obj_refcount = 2 (drm_gem_object_handle_reference)
handle_refcount = 2 (drm_gem_object_handle_reference)
i915_gem_create_ioctl then does:
obj_refcount = 1 (drm_gem_object_handle_unreference)
handle_refcount = 1 (drm_gem_object_handle_unreference)
Your patch looks like you'd now leave i915_gem_create_ioctl with
obj_refcount = 1, handle_refcount = 2. So on app close, the
handle_unreference wouldn't get handle_refcount to 0, and named objects
would never get freed.
--
Eric Anholt
eric at anholt.net eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20090527/047548cc/attachment.sig>
More information about the Intel-gfx
mailing list