[Outreachy kernel] [PATCH v2] drm: Remove obsolete "This is gross" comment

[Daniel Vetter]

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 at gmail.com>
> ---
> 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 at googlegroups.com.
> To post to this group, send email to outreachy-kernel at googlegroups.com.
> 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