drm: Remove obsolete "This is gross" comment
Subsystems (3)
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
@@ -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
@@ -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
Quoted 11 lines · Haneen Mohammed
Remove obsolete comment which was initially added in 2008 to annotate that
idr_find()was used beforeidr_remove()sinceidr_remove()didn't use to return feedback. The comment now is irrelevant with commitf6cd7daecff5("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 <[email protected]>---
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@@ -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@@ -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