On Thu, Sep 21, 2017 at 07:34:09PM -0600, Haneen Mohammed wrote:
> Remove obsolete comment which was initially added in 2008 to annotate
> that idr_find() was used before idr_remove() since idr_remove() didn't
> use to return feedback. The comment now is irrelevant with
> commit f6cd7daecff5 ("drm: Release driver references to handle before
> making it available again").
> In addition, remove the todo item about this issue.
>
> Signed-off-by: Haneen Mohammed <hamohammed.sa@xxxxxxxxx>
> ---
> Changes in v2:
> - remove todo item regarding this comment
Oh drat, I applied v1. Let's blame this on my bad case of a jetlag :-/
Can you pls send a new patch which just removes the todo entry? Sorry
about the confusion.
-Daniel
>
> Documentation/gpu/todo.rst | 6 ------
> drivers/gpu/drm/drm_gem.c | 9 ---------
> 2 files changed, 15 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 22af55d..5e96dc7 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -180,12 +180,6 @@ Contact: Daniel Vetter, respective driver maintainers
> Core refactorings
> =================
>
> -Use new IDR deletion interface to clean up drm_gem_handle_delete()
> -------------------------------------------------------------------
> -
> -See the "This is gross" comment -- apparently the IDR system now can return an
> -error code instead of oopsing.
> -
> Clean up the DRM header mess
> ----------------------------
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index c55f338..b9bddaa 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -282,15 +282,6 @@ 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 */
> --
> 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/20170922013409.GA2741%40Haneen.
> 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
