Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
Summary: Restricting drm open file descriptors (AIGLX deadlock)
Version: DRI CVS
There is a drm problem having processes with multiple drm file descriptors open,
since a deadlock may occur when DRM tries to grab the lock for the kernel context.
This is, AFAICT only done for drm drivers implementing reclaim_buffers_locked, but
in general the kernel needs to grab the lock for the kernel context when it needs to
wait for engine idle for some reason.
In the X server case, we have the following situation:
1) The 2D driver opens a drm file descriptor.
2) The 2D driver obtains the hardware lock.
3) AIGLX opens a drm file descriptor.
4) AIGLX closes the file descriptor.
Point 4 triggers a reclaim_buffers_locked() call, and the kernel tries to grab
the lock. It then
senses that the lock is not associated with the closing file descriptor and
waits for the lock to be
released. This will never happen since the X server is waiting for 4) to
complete, and a deadlock
To solve this, we could either try to make DRM smarter by tracking the thread
holding the lock, or we can restrict DRM open file descriptors to one per
thread. Currently any 2D driver using a DRM driver implementing
reclaim_buffers_locked() will deadlock when AIGLX is enabled.
The DRM locking mechanism is currently assuming that for a given context, the hw
lock should only be obtained using a single file descriptor. Otherwise, DRM will
lose track of the file descriptor used to obtain the lock.
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.