[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