On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> The IDR deletion interface now returns the deleted entry or NULL if it was not
> present. So we don't have to do the extra work of checking if we have a
> reference on the drm_gem_object, this can be handled by checking the return
> value from idr_remove() and the extra locks can be dropped.
>
> Signed-off-by: Aishwarya Pant <aishpant@xxxxxxxxx>
Haneen is already working on this task, with the patch just merged. Please
coordinate with mentors (me or Sean Paul) before starting on something to
avoid such clashes in the future.
Note also that some todo items are just ideas, and need confirmation with
relevant maintainers first.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_gem.c | 21 ++-------------------
> 1 file changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index c55f338..f62757a 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -282,29 +282,12 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
> {
> struct drm_gem_object *obj;
>
> - /* This is gross. The idr system doesn't let us try a delete and
> - * return an error code. It just spews if you fail at deleting.
> - * So, we have to grab a lock around finding the object and then
> - * doing the delete on it and dropping the refcount, or the user
> - * could race us to double-decrement the refcount and cause a
> - * use-after-free later. Given the frequency of our handle lookups,
> - * we may want to use ida for number allocation and a hash table
> - * for the pointers, anyway.
> - */
> spin_lock(&filp->table_lock);
> -
> - /* Check if we currently have a reference on the object */
> - obj = idr_replace(&filp->object_idr, NULL, handle);
> - spin_unlock(&filp->table_lock);
> - if (IS_ERR_OR_NULL(obj))
> + obj = idr_remove(&filp->object_idr, handle);
> + if (!obj)
> return -EINVAL;
> -
> /* Release driver's reference and decrement refcount. */
> drm_gem_object_release_handle(handle, obj, filp);
> -
> - /* And finally make the handle available for future allocations. */
> - spin_lock(&filp->table_lock);
> - idr_remove(&filp->object_idr, handle);
> spin_unlock(&filp->table_lock);
>
> return 0;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@xxxxxxxxxxxxxxxx.
> To post to this group, send email to outreachy-kernel@xxxxxxxxxxxxxxxx.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> For more options, visit https://groups.google.com/d/optout.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
