Skip to contentSkip to conversation

drm: Remove obsolete "This is gross" comment

PATCH In review Haneen Mohammed 2 participants 2 messages Sep 22, 2017 – Sep 26, 2017

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 drm: Remove obsolete "This is gross" comment

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.

---
Changes in v2:
- remove todo item regarding this comment

 Documentation/gpu/todo.rst | 6 ------
 drivers/gpu/drm/drm_gem.c  | 9 ---------
 2 files changed, 15 deletions(-)
Documentation/gpu/todo.rst +0 -6
index 22af55d..5e96dc7 100644
@@ -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
 ----------------------------
 
drivers/gpu/drm/drm_gem.c +0 -9
index c55f338..b9bddaa 100644
@@ -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 */
Signature · 1 line
2.7.4
#1 lore raw
Quoted 11 lines · Haneen Mohammed

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.

---
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

Quoted 51 lines
 Documentation/gpu/todo.rst | 6 ------
 drivers/gpu/drm/drm_gem.c  | 9 ---------
 2 files changed, 15 deletions(-)
Documentation/gpu/todo.rst +0 -6
index 22af55d..5e96dc7 100644
@@ -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
 ----------------------------
 
drivers/gpu/drm/drm_gem.c +0 -9
index c55f338..b9bddaa 100644
@@ -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 */
Signature · 8 lines
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 [email protected].
To post to this group, send email to [email protected].
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.
Signature · 3 lines
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch