drm: Remove obsolete "This is gross" comment
Subsystems (2)
PATCH RESEND 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").
--- drivers/gpu/drm/drm_gem.c | 9 --------- 1 file changed, 9 deletions(-)
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 · 6 lines
2.7.4 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoted 5 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").
Why did you send it again?
julia
Quoted 36 lines
Signed-off-by Haneen Mohammed <[email protected]>--- drivers/gpu/drm/drm_gem.c | 9 --------- 1 file changed, 9 deletions(-)drivers/gpu/drm/drm_gem.c +0
-10@@ -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 [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/20170921210424.GA21951%40Haneen.
For more options, visit https://groups.google.com/d/optout.
Quoted 10 lines · Julia Lawall
Quoted 5 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").
Quoted 4 lines
Why did you send it again?
julia
I forgot to include the dri-devel mailing list for the first patch.
Haneen
Quoted 29 lines
Quoted 29 lines
Signed-off-by Haneen Mohammed <[email protected]>--- drivers/gpu/drm/drm_gem.c | 9 --------- 1 file changed, 9 deletions(-)drivers/gpu/drm/drm_gem.c +0
-10@@ -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
Quoted 7 lines
Quoted 7 lines
--
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/20170921210424.GA21951%40Haneen.
For more options, visit https://groups.google.com/d/optout.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoted 11 lines · Haneen Mohammed
Quoted 10 lines · Julia Lawall
Quoted 5 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").
Quoted 6 lines
Quoted 4 lines
Why did you send it again?
julia
I forgot to include the dri-devel mailing list for the first patch.
OK, it should have been a v2 with a comment about what changed. Even if it is not a technical issue, it saves people wondering about what happened.
julia
Quoted 47 lines
Haneen
Quoted 29 lines
Quoted 29 lines
Signed-off-by Haneen Mohammed <[email protected]>--- drivers/gpu/drm/drm_gem.c | 9 --------- 1 file changed, 9 deletions(-)drivers/gpu/drm/drm_gem.c +0
-10@@ -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
Quoted 7 lines
Quoted 7 lines
--
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/20170921210424.GA21951%40Haneen.
For more options, visit https://groups.google.com/d/optout.--
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/20170921214707.GA22325%40Haneen.
For more options, visit https://groups.google.com/d/optout.
Quoted 20 lines · Julia Lawall
Quoted 16 lines · Haneen Mohammed
Quoted 14 lines · Julia Lawall
Quoted 5 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").Why did you send it again?
julia
Quoted 7 lines
Quoted 1 line
I forgot to include the dri-devel mailing list for the first patch.
OK, it should have been a v2 with a comment about what changed. Even if it is not a technical issue, it saves people wondering about what happened.
julia
I see. I thought only if I introduced a change to the patch I should make a new version. Thank you, I will take this into account next time!
-Haneen
Quoted 48 lines
Quoted 48 lines
Haneen
Quoted 29 lines
Quoted 29 lines
Signed-off-by Haneen Mohammed <[email protected]>--- drivers/gpu/drm/drm_gem.c | 9 --------- 1 file changed, 9 deletions(-)drivers/gpu/drm/drm_gem.c +0
-10@@ -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
Quoted 7 lines
Quoted 7 lines
--
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/20170921210424.GA21951%40Haneen.
For more options, visit https://groups.google.com/d/optout.--
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/20170921214707.GA22325%40Haneen.
For more options, visit https://groups.google.com/d/optout.
Daniel Vetter
AppliedQuoted 5 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").
Personally I'd have added a lot more of the research story you've detailed in the private mails, just to show the work you've done. But the terse version is ok too ofc.
Quoted 1 line
Signed-off-by Haneen Mohammed <[email protected]>
Applied to drm-misc-next, thanks.
-Daniel
Quoted 33 lines
--- drivers/gpu/drm/drm_gem.c | 9 --------- 1 file changed, 9 deletions(-)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/20170921210424.GA21951%40Haneen. For more options, visit https://groups.google.com/d/optout.
Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Quoted 7 lines · Daniel Vetter
Quoted 5 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").
Quoted 9 lines
Personally I'd have added a lot more of the research story you've detailed in the private mails, just to show the work you've done. But the terse version is ok too ofc.
Quoted 1 line
Signed-off-by Haneen Mohammed <[email protected]>Applied to drm-misc-next, thanks.
-Daniel
My bad, I was afraid to add too much details as I always read commit message should be concise that I then ended up with too little.
I will try next time to add the necessary information.
Thank you!
Haneen
Quoted 27 lines
Quoted 27 lines
--- drivers/gpu/drm/drm_gem.c | 9 --------- 1 file changed, 9 deletions(-)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
Quoted 6 lines
Signature · 5 lines
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/20170921210424.GA21951%40Haneen. For more options, visit https://groups.google.com/d/optout.Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel