i-g-t test for gem flink race

[Daniel Vetter]

On Fri, Dec 21, 2012 at 3:46 AM, Dave Airlie <airlied at gmail.com> wrote:
> On Fri, Dec 21, 2012 at 11:49 AM, Dave Airlie <airlied at gmail.com> wrote:
>> As we talked on irc, I decided to write a test case and it actually
>> seems to trigger the race.
>>
>> Really its insane userspace behaviour and I'm not really sure we
>> should care to fix, I can't see it causing an oops, more userspace
>> does something insane, it gets a bad result, but I'll contemplate it a
>> bit more.
>
> Yeah after considering this a bit more, I really think its just a
> userspace problem, don''t go closing gem object handles that other
> threads could be using. Lets state any result after doing something
> like that is undefined, and the current behaviour is within spec.

Yeah, I've looked at the code again and I think we can't oops or leak
stuff with the current code. But userspace could end up with a gem
handle and a removed flink name, but I agree now that we don't need to
care about this for flink. Important is just that a non-zero flink
can't be observed without a corresponding reference, for otherwise
we'd need to resurrect zombies. I've looked a the code again and I
think we're safe.

Looking at dma-buf I think the same applies, if userspace races
imports against gem_close it's kinda not our problem. I've thought for
a while that for cross-process situations we need better guarantees
since the dma-buf can exists on its own and doesn't need an open
userspace gem handle to survive like an flink name. But then I think
we just have to be careful with locking at import time to so that we
don't end up with two gem objects for the same dma-buf somehow. Much
simpler than worrying about close vs. import races.

For the racing igt test itself I think that one could still be useful
- just make it never fail and we can use it to hunt for leaks and
other issues in that code.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch