Re: X server steals DRI lock

[Thomas Hellström]

Hi! Dave Airlie wrote: I have an application that takes the hardware DRI lock and then does an usleep(1) while polling hardware status. Entering the polling function, I've verified that the lock is indeed taken 0x80000002, with 2 corresponding to the correct DRM context. Upon exit from the polling function, sometimes the X server has stolen the lock, 0x80000001, or even 0x1, signalling the X server already did it's processing. The lock has never been touched by the application in-between. Don't sleep holding the lock unless you have a good reason, the X server will take it back forcibly if it can't get it nicely as it is in charge and a locked up Xserver waiting for a client is a bad idea in terms of sharing resources.. it would be a DoS if a DRI client can just take the lock and sit on it .. take a look at the programs/Xserver/GL/dri/dri.c:DRISpinLockTimeout /* Didn't get lock, so take it. The worst that can happen is that there is some garbage written to the wrong part of the framebuffer that a refresh will repair. That's undesirable, but better than locking the server. This should be a very rare event. */ is a comment from that function.. Dave. I don't think this is the cause of the problem, since what you're referring to above is IIRC a drawable spinlock, not the heavyweight hardware lock. If a client takes the heavyweight lock and then sleeps even for a couple of seconds, the X server should freeze during this time, which it also usually does. In this case (the Mesa testcase) we're talking the minimal amount of sleep available (1ms on 2.6 kernels), and from what I can see in the above file, the X server uses DRM_LOCK, which immediately calls the kernel if the cmpxchg fails. /Thomas