-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it either. Did I miss something, or is this intended behaviour? It certainly seems strange to me.
Also, it is possible for a DRI client to effectively lock up the entire machine simply by entering an endless loop after taking the lock. I suppose one could still log in remotely and kill the offending process, but that's not a realistic option for most people. Switching to a different VT or killing the X server does not work, because the X server has to take the DRI lock in the process. This is a problem that I want to fix (it makes playing around with the R300 hack Vladimir Dergachev posted an infinite-rebooting nightmare), but I am unsure what the best solution would be. As far as I can see, the problem is two-fold: One, the X server must be able to "break" the lock, and two, it (or the DRM) must somehow disable the offending DRI client to prevent the problem from reoccurring. I think the simplest solution would look something like this: Whenever DRM(lock) is called by a privileged client (i.e. the X server), and it needs to sleep because the lock is held by an unprivileged client, a watchdog timer is started before we schedule. DRM(unlock) unconditionally stops this watchdog timer. When the watchdog timer fires, it releases the lock and/or kills the offending DRI client. Side question: Is killing the offending DRI client enough? When the process is killed, the /dev/drm fd is closed, which should automatically release the lock. On the other hand, I'm pretty sure that we can't just kill a process immediately (unfortunately, I'm not familiar with process handling in the kernel). What if, for some reason, the process is in a state where it can't be killed yet? I guess this isn't a problem when we're dealing with a faulty 3D driver, but it might be a problem when dealing with malicious code. Side question #2: Is it safe to release the DRM lock in the watchdog? There might be races where the offending DRI client is currently executing a DRM ioctl when the watchdog fires. This solution involves no ABI changes. Since all changes are kernel side and affect only code that is shared between all drivers, everybody would benefit immediately. Does this all look reasonable to the DRI gurus? cu, Nicolai -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAr0G+sxPozBga0lwRAmqlAJ9fzmVB1t5D5Hqna3QoGD4zwv1suwCgqyZ1 tWYeGKKr22zwJuR3WNsFzjc= =M43m -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
