Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Aishwarya Pant]

On Tue, Sep 26, 2017 at 10:20:47AM +0200, Daniel Vetter wrote:
> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> > The IDR deletion interface now returns the deleted entry or NULL if it was 
> > not
> > present. So we don't have to do the extra work of checking if we have a
> > reference on the drm_gem_object, this can be handled by checking the return
> > value from idr_remove() and the extra locks can be dropped.
> > 
> > Signed-off-by: Aishwarya Pant 
> 
> Haneen is already working on this task, with the patch just merged. Please
> coordinate with mentors (me or Sean Paul) before starting on something to
> avoid such clashes in the future.

Apologies for the mix-up, I'll make sure to check in with the mentors before
starting a task.

I looked over the other patch sent by Haneen today, there is one thing that I
could use some clarity on. I'm not sure how the -this is gross- comment is
obsolete since we can drop the check to idr_replace() and use the return value
from idr_remove() which seems neater in my opinion.

> 
> Note also that some todo items are just ideas, and need confirmation with
> relevant maintainers first.
> 
> Thanks, Daniel
> > ---
> >  drivers/gpu/drm/drm_gem.c | 21 ++---
> >  1 file changed, 2 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index c55f338..f62757a 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -282,29 +282,12 @@ 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(>table_lock);
> > -
> > -   /* Check if we currently have a reference on the object */
> > -   obj = idr_replace(>object_idr, NULL, handle);
> > -   spin_unlock(>table_lock);
> > -   if (IS_ERR_OR_NULL(obj))
> > +   obj = idr_remove(>object_idr, handle);
> > +   if (!obj)
> > return -EINVAL;
> > -
> > /* Release driver's reference and decrement refcount. */
> > drm_gem_object_release_handle(handle, obj, filp);
> > -
> > -   /* And finally make the handle available for future allocations. */
> > -   spin_lock(>table_lock);
> > -   idr_remove(>object_idr, handle);
> > spin_unlock(>table_lock);
> >  
> > return 0;
> > -- 
> > 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+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> > 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Julia Lawall]

On Tue, 26 Sep 2017, Daniel Vetter wrote:

> On Tue, Sep 26, 2017 at 10:47 AM, Daniel Vetter  wrote:
> > On Tue, Sep 26, 2017 at 10:38 AM, Julia Lawall  wrote:
> >>
> >>
> >> On Tue, 26 Sep 2017, Daniel Vetter wrote:
> >>
> >>> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> >>> > The IDR deletion interface now returns the deleted entry or NULL if it 
> >>> > was not
> >>> > present. So we don't have to do the extra work of checking if we have a
> >>> > reference on the drm_gem_object, this can be handled by checking the 
> >>> > return
> >>> > value from idr_remove() and the extra locks can be dropped.
> >>> >
> >>> > Signed-off-by: Aishwarya Pant 
> >>>
> >>> Haneen is already working on this task, with the patch just merged. Please
> >>> coordinate with mentors (me or Sean Paul) before starting on something to
> >>> avoid such clashes in the future.
> >>>
> >>> Note also that some todo items are just ideas, and need confirmation with
> >>> relevant maintainers first.
> >>
> >> Not sure where the mixup happened, but anyone who starts on a project
> >> specific task should note that on the outreachy kernel wiki and before
> >> starting on a project specific task one should check that no one is
> >> working on it.  If someone started some time ago, and the code doesn't
> >> seem to have changed, ask the person who claimed the task or the mentor.
> >
> > Hm, the dri-devel tasks aren't on the wiki, but in the kernel sources.
> > Where should we put the scratch-pad to avoid such conflicts in the
> > future? E.g. the IIO subsytems has it's task on the wiki, where this
> > works much better.
>
> Ok, I found it. Looks like a few signed up for stuff, but without
> chatting with us first, and ended up picking tasks that need some
> serious GPU expertise. I.e. maybe suitable for a full internship,
> definitely not as starter tasks. I'll send out mails.

Thanks.  Everyone, please discuss with the mentor before picking a task.

julia

> -Daniel
>
>
> > -Daniel
> >
> >>
> >> thanks,
> >>
> >> julia
> >>
> >>>
> >>> Thanks, Daniel
> >>> > ---
> >>> >  drivers/gpu/drm/drm_gem.c | 21 ++---
> >>> >  1 file changed, 2 insertions(+), 19 deletions(-)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> >>> > index c55f338..f62757a 100644
> >>> > --- a/drivers/gpu/drm/drm_gem.c
> >>> > +++ b/drivers/gpu/drm/drm_gem.c
> >>> > @@ -282,29 +282,12 @@ 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(>table_lock);
> >>> > -
> >>> > -   /* Check if we currently have a reference on the object */
> >>> > -   obj = idr_replace(>object_idr, NULL, handle);
> >>> > -   spin_unlock(>table_lock);
> >>> > -   if (IS_ERR_OR_NULL(obj))
> >>> > +   obj = idr_remove(>object_idr, handle);
> >>> > +   if (!obj)
> >>> > return -EINVAL;
> >>> > -
> >>> > /* Release driver's reference and decrement refcount. */
> >>> > drm_gem_object_release_handle(handle, obj, filp);
> >>> > -
> >>> > -   /* And finally make the handle available for future allocations. */
> >>> > -   spin_lock(>table_lock);
> >>> > -   idr_remove(>object_idr, handle);
> >>> > spin_unlock(>table_lock);
> >>> >
> >>> > return 0;
> >>> > --
> >>> > 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+unsubscr...@googlegroups.com.
> >>> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> >>> > To view this discussion on the web visit 
> >>> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> >>> > For more options, visit https://groups.google.com/d/optout.
> >>>
> >>> --
> >>> Daniel Vetter
> >>> Software Engineer, Intel Corporation
> >>> http://blog.ffwll.ch
> >>>
> >>> --
> >>> 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+unsubscr...@googlegroups.com.
> >>> To post to this group, send email to 

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Daniel Vetter]

On Tue, Sep 26, 2017 at 10:47 AM, Daniel Vetter  wrote:
> On Tue, Sep 26, 2017 at 10:38 AM, Julia Lawall  wrote:
>>
>>
>> On Tue, 26 Sep 2017, Daniel Vetter wrote:
>>
>>> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
>>> > The IDR deletion interface now returns the deleted entry or NULL if it 
>>> > was not
>>> > present. So we don't have to do the extra work of checking if we have a
>>> > reference on the drm_gem_object, this can be handled by checking the 
>>> > return
>>> > value from idr_remove() and the extra locks can be dropped.
>>> >
>>> > Signed-off-by: Aishwarya Pant 
>>>
>>> Haneen is already working on this task, with the patch just merged. Please
>>> coordinate with mentors (me or Sean Paul) before starting on something to
>>> avoid such clashes in the future.
>>>
>>> Note also that some todo items are just ideas, and need confirmation with
>>> relevant maintainers first.
>>
>> Not sure where the mixup happened, but anyone who starts on a project
>> specific task should note that on the outreachy kernel wiki and before
>> starting on a project specific task one should check that no one is
>> working on it.  If someone started some time ago, and the code doesn't
>> seem to have changed, ask the person who claimed the task or the mentor.
>
> Hm, the dri-devel tasks aren't on the wiki, but in the kernel sources.
> Where should we put the scratch-pad to avoid such conflicts in the
> future? E.g. the IIO subsytems has it's task on the wiki, where this
> works much better.

Ok, I found it. Looks like a few signed up for stuff, but without
chatting with us first, and ended up picking tasks that need some
serious GPU expertise. I.e. maybe suitable for a full internship,
definitely not as starter tasks. I'll send out mails.
-Daniel


> -Daniel
>
>>
>> thanks,
>>
>> julia
>>
>>>
>>> Thanks, Daniel
>>> > ---
>>> >  drivers/gpu/drm/drm_gem.c | 21 ++---
>>> >  1 file changed, 2 insertions(+), 19 deletions(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>>> > index c55f338..f62757a 100644
>>> > --- a/drivers/gpu/drm/drm_gem.c
>>> > +++ b/drivers/gpu/drm/drm_gem.c
>>> > @@ -282,29 +282,12 @@ 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(>table_lock);
>>> > -
>>> > -   /* Check if we currently have a reference on the object */
>>> > -   obj = idr_replace(>object_idr, NULL, handle);
>>> > -   spin_unlock(>table_lock);
>>> > -   if (IS_ERR_OR_NULL(obj))
>>> > +   obj = idr_remove(>object_idr, handle);
>>> > +   if (!obj)
>>> > return -EINVAL;
>>> > -
>>> > /* Release driver's reference and decrement refcount. */
>>> > drm_gem_object_release_handle(handle, obj, filp);
>>> > -
>>> > -   /* And finally make the handle available for future allocations. */
>>> > -   spin_lock(>table_lock);
>>> > -   idr_remove(>object_idr, handle);
>>> > spin_unlock(>table_lock);
>>> >
>>> > return 0;
>>> > --
>>> > 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+unsubscr...@googlegroups.com.
>>> > To post to this group, send email to outreachy-ker...@googlegroups.com.
>>> > To view this discussion on the web visit 
>>> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> http://blog.ffwll.ch
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/outreachy-kernel/20170926082047.eqsd2lslpqp4pi5f%40phenom.ffwll.local.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Daniel Vetter]

On Tue, Sep 26, 2017 at 10:38 AM, Julia Lawall  wrote:
>
>
> On Tue, 26 Sep 2017, Daniel Vetter wrote:
>
>> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
>> > The IDR deletion interface now returns the deleted entry or NULL if it was 
>> > not
>> > present. So we don't have to do the extra work of checking if we have a
>> > reference on the drm_gem_object, this can be handled by checking the return
>> > value from idr_remove() and the extra locks can be dropped.
>> >
>> > Signed-off-by: Aishwarya Pant 
>>
>> Haneen is already working on this task, with the patch just merged. Please
>> coordinate with mentors (me or Sean Paul) before starting on something to
>> avoid such clashes in the future.
>>
>> Note also that some todo items are just ideas, and need confirmation with
>> relevant maintainers first.
>
> Not sure where the mixup happened, but anyone who starts on a project
> specific task should note that on the outreachy kernel wiki and before
> starting on a project specific task one should check that no one is
> working on it.  If someone started some time ago, and the code doesn't
> seem to have changed, ask the person who claimed the task or the mentor.

Hm, the dri-devel tasks aren't on the wiki, but in the kernel sources.
Where should we put the scratch-pad to avoid such conflicts in the
future? E.g. the IIO subsytems has it's task on the wiki, where this
works much better.
-Daniel

>
> thanks,
>
> julia
>
>>
>> Thanks, Daniel
>> > ---
>> >  drivers/gpu/drm/drm_gem.c | 21 ++---
>> >  1 file changed, 2 insertions(+), 19 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>> > index c55f338..f62757a 100644
>> > --- a/drivers/gpu/drm/drm_gem.c
>> > +++ b/drivers/gpu/drm/drm_gem.c
>> > @@ -282,29 +282,12 @@ 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(>table_lock);
>> > -
>> > -   /* Check if we currently have a reference on the object */
>> > -   obj = idr_replace(>object_idr, NULL, handle);
>> > -   spin_unlock(>table_lock);
>> > -   if (IS_ERR_OR_NULL(obj))
>> > +   obj = idr_remove(>object_idr, handle);
>> > +   if (!obj)
>> > return -EINVAL;
>> > -
>> > /* Release driver's reference and decrement refcount. */
>> > drm_gem_object_release_handle(handle, obj, filp);
>> > -
>> > -   /* And finally make the handle available for future allocations. */
>> > -   spin_lock(>table_lock);
>> > -   idr_remove(>object_idr, handle);
>> > spin_unlock(>table_lock);
>> >
>> > return 0;
>> > --
>> > 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+unsubscr...@googlegroups.com.
>> > To post to this group, send email to outreachy-ker...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/outreachy-kernel/20170926082047.eqsd2lslpqp4pi5f%40phenom.ffwll.local.
>> For more options, visit https://groups.google.com/d/optout.
>>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Julia Lawall]

On Tue, 26 Sep 2017, Daniel Vetter wrote:

> On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> > The IDR deletion interface now returns the deleted entry or NULL if it was 
> > not
> > present. So we don't have to do the extra work of checking if we have a
> > reference on the drm_gem_object, this can be handled by checking the return
> > value from idr_remove() and the extra locks can be dropped.
> >
> > Signed-off-by: Aishwarya Pant 
>
> Haneen is already working on this task, with the patch just merged. Please
> coordinate with mentors (me or Sean Paul) before starting on something to
> avoid such clashes in the future.
>
> Note also that some todo items are just ideas, and need confirmation with
> relevant maintainers first.

Not sure where the mixup happened, but anyone who starts on a project
specific task should note that on the outreachy kernel wiki and before
starting on a project specific task one should check that no one is
working on it.  If someone started some time ago, and the code doesn't
seem to have changed, ask the person who claimed the task or the mentor.

thanks,

julia

>
> Thanks, Daniel
> > ---
> >  drivers/gpu/drm/drm_gem.c | 21 ++---
> >  1 file changed, 2 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index c55f338..f62757a 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -282,29 +282,12 @@ 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(>table_lock);
> > -
> > -   /* Check if we currently have a reference on the object */
> > -   obj = idr_replace(>object_idr, NULL, handle);
> > -   spin_unlock(>table_lock);
> > -   if (IS_ERR_OR_NULL(obj))
> > +   obj = idr_remove(>object_idr, handle);
> > +   if (!obj)
> > return -EINVAL;
> > -
> > /* Release driver's reference and decrement refcount. */
> > drm_gem_object_release_handle(handle, obj, filp);
> > -
> > -   /* And finally make the handle available for future allocations. */
> > -   spin_lock(>table_lock);
> > -   idr_remove(>object_idr, handle);
> > spin_unlock(>table_lock);
> >
> > return 0;
> > --
> > 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+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170926082047.eqsd2lslpqp4pi5f%40phenom.ffwll.local.
> For more options, visit https://groups.google.com/d/optout.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

[Daniel Vetter]

On Tue, Sep 26, 2017 at 12:17:28AM +0530, Aishwarya Pant wrote:
> The IDR deletion interface now returns the deleted entry or NULL if it was not
> present. So we don't have to do the extra work of checking if we have a
> reference on the drm_gem_object, this can be handled by checking the return
> value from idr_remove() and the extra locks can be dropped.
> 
> Signed-off-by: Aishwarya Pant 

Haneen is already working on this task, with the patch just merged. Please
coordinate with mentors (me or Sean Paul) before starting on something to
avoid such clashes in the future.

Note also that some todo items are just ideas, and need confirmation with
relevant maintainers first.

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_gem.c | 21 ++---
>  1 file changed, 2 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index c55f338..f62757a 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -282,29 +282,12 @@ 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(>table_lock);
> -
> - /* Check if we currently have a reference on the object */
> - obj = idr_replace(>object_idr, NULL, handle);
> - spin_unlock(>table_lock);
> - if (IS_ERR_OR_NULL(obj))
> + obj = idr_remove(>object_idr, handle);
> + if (!obj)
>   return -EINVAL;
> -
>   /* Release driver's reference and decrement refcount. */
>   drm_gem_object_release_handle(handle, obj, filp);
> -
> - /* And finally make the handle available for future allocations. */
> - spin_lock(>table_lock);
> - idr_remove(>object_idr, handle);
>   spin_unlock(>table_lock);
>  
>   return 0;
> -- 
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170925184728.GA8861%40aishwarya.
> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel