On Fri, Dec 21, 2012 at 3:46 AM, Dave Airlie <airlied@xxxxxxxxx> wrote: > On Fri, Dec 21, 2012 at 11:49 AM, Dave Airlie <airlied@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
