From: <bug...@an...> - 2006-12-27 11:05:17
|
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. https://bugs.freedesktop.org/show_bug.cgi?id=9457 Summary: Restricting drm open file descriptors (AIGLX deadlock) Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: General AssignedTo: dri...@li... ReportedBy: th...@tu... 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 has occured. 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. |