GEM - radeon cs ioctl deadlock
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 at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
Re: GEM - radeon cs ioctl deadlock
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
GEM - radeon cs ioctl deadlock
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 at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
GEM - radeon cs ioctl deadlock
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
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
GEM - radeon cs ioctl deadlock
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
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
GEM - radeon cs ioctl deadlock
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
