On 12/18/2013 09:25 AM, Daniel Vetter wrote:
On Wed, Dec 18, 2013 at 11:39:27AM +1000, Dave Airlie wrote:
On Wed, Dec 11, 2013 at 8:34 PM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
Since this is all old ums stuff (including the one in the radeon driver) I've just tried to perfectly replicate the existing semantics.
Reinventing wait queue code with semantics that differ from all the standard linux wait functions is just hairy, so now we can get rid of this and so make sure it'll never again be used.
Oh and: via futexes ... *shudder*
This one worries me, I've had numerous attempts to rip this out in the past and they always changed semantics on some devices and broke stuff.
The sneaky timeout is essential for a lot of the hardware
https://urldefense.proofpoint.com/v1/url?u=http://marc.info/?l%3Ddri-devel%2...
So I think I'd like a few more people to review this one before I go near it again :-)
Oh, and I've thought the only tricky stuff is mapping the errno's correctly. I think if we have such cases of racy drivers then the right thing to do is to shovel this macro into drivers and slap a big comment about signalling races on top of that code.
Thomas report doesn't say so, but I guess it's for via. Thomas, do you still have a vague recollection of what this has been about?
Yes, this was with via, but IIRC there were other drivers affected as well, but OTOH, I think the kernel wait code was fixed for races some time after that....
/Thomas
Dave, do you want me to just respin this one with via left as-is (and the macro pushed into the via driver)?
Thanks, Daniel