GEM - radeon cs ioctl deadlock

GEM - radeon cs ioctl deadlock

[Jerome Glisse]

So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
a name (with flink) we could endup with 2 handle pointing to the same
object (flink object and open it from same file descriptor). Would it be ok
if i change gem open to first look if we already have an handle for the
object and to use that handle instead of creating a new one ? Or could
this break intel driver ?

Cheers,
Jerome

Re: GEM - radeon cs ioctl deadlock

[Dave Airlie]

On Wed, 2010-10-13 at 17:57 -0400, Jerome Glisse wrote:
> So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
> a name (with flink) we could endup with 2 handle pointing to the same
> object (flink object and open it from same file descriptor). Would it be ok
> if i change gem open to first look if we already have an handle for the
> object and to use that handle instead of creating a new one ? Or could
> this break intel driver ?

I think r300g worked around this already, maybe we should just avoid
doing it from userspace if possible.

Dave.

Re: GEM - radeon cs ioctl deadlock

[Ben Skeggs]

On Thu, 2010-10-14 at 08:14 +1000, Dave Airlie wrote:
> On Wed, 2010-10-13 at 17:57 -0400, Jerome Glisse wrote:
> > So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
> > a name (with flink) we could endup with 2 handle pointing to the same
> > object (flink object and open it from same file descriptor). Would it be ok
> > if i change gem open to first look if we already have an handle for the
> > object and to use that handle instead of creating a new one ? Or could
> > this break intel driver ?
> 
> I think r300g worked around this already, maybe we should just avoid
> doing it from userspace if possible.
We had this in nouveau at some point.  In the end, I prevented the
deadlock from occuring by checking that a process doesn't reserve the
same buffer twice (we store file_priv in a reserved_by field in the bo
as we reserve the buffers), and then just fixed userspace.

Ben.
> 
> Dave.
> 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GEM - radeon cs ioctl deadlock

[Thomas Hellstrom]

On 10/14/2010 03:47 AM, Ben Skeggs wrote:
> On Thu, 2010-10-14 at 08:14 +1000, Dave Airlie wrote:
>    
>> On Wed, 2010-10-13 at 17:57 -0400, Jerome Glisse wrote:
>>      
>>> So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
>>> a name (with flink) we could endup with 2 handle pointing to the same
>>> object (flink object and open it from same file descriptor). Would it be ok
>>> if i change gem open to first look if we already have an handle for the
>>> object and to use that handle instead of creating a new one ? Or could
>>> this break intel driver ?
>>>        
>> I think r300g worked around this already, maybe we should just avoid
>> doing it from userspace if possible.
>>      
> We had this in nouveau at some point.  In the end, I prevented the
> deadlock from occuring by checking that a process doesn't reserve the
> same buffer twice (we store file_priv in a reserved_by field in the bo
> as we reserve the buffers), and then just fixed userspace.
>
> Ben.
>    
>>      
Hi, Ben,

Without knowing the exact details, that sounds a little dangerous? It 
would be better to use a process identifier rather than a file 
identifier since multiple threads in a single client can and should use 
the same file descriptor.

/Thomas


>> Dave.
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>      
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>