Summary: | Restricting drm open file descriptors (AIGLX deadlock) | ||
---|---|---|---|
Product: | DRI | Reporter: | Thomas Hellström <thomas> |
Component: | General | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED INVALID | QA Contact: | |
Severity: | major | ||
Priority: | high | CC: | krh |
Version: | DRI git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Thomas Hellström
2006-12-27 03:05:12 UTC
I've been thinking a bit about this: reclaim_buffers_locked() probably only needs the lock to be able to wait for engine idle without waiting forever. (The discussion is based on this). We need a similar mechanism for fence object implementations on simple hardware that only wait for engine idle and after that declares all active fence objects as signaled. Wit this in mind, we could probably attach a kernel reference counter to the hardware lock that, if non-zero, indicates that the kernel wants the lock if it is released. The lock itself is marked contended if held by somebody else. Now, when the lock is released it is grabbed by the kernel and released when the refcount goes to zero. The following situations can occur: 1) Engine is idle without the kernel ever grabbing the lock. All is fine, fences can be expired and buffers can be reclaimed, and the refcount will be decreased. This is the situaton when the current process holds the lock, and since we've been waiting for idle, no new command submissions can occur anyway. 2) The kernel succeeds in grabbing the lock. All is well. This would get rid of some ugly code and save us from restricting the number of open file descriptors. /Thomas Isn't it just a bug that AIGLX opens/closes DRM file descriptors while holding the lock? That said, the patch you posted to the dri-devel list probably has other merits though. Yes, but there's more to the problem. It will occur with any app that has more than one file descriptor open to drm. If it grabs the lock and then dies, the file descriptors will be closed in an arbitrary order, and possibly a file descriptor not holding the lock will be closed first and a deadlock will occur. So while AIGLX could be fixed, the problem will probably pop up in the future. Thomas Hellström Do you still experience this issue with newer soft ? Please check the status of your issue. Twelve year old issue, closing. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.