[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #44 from Suzuki, Shinji <shinji.suzuki at gmail.com> ---
> screen->fence_reference(screen, &fence, NULL);
>
> is always thread-safe with a local variable fence,
That case is thread-safe not because the variable is local but because
concurrent execution is not possible because the variable is local. :)

>Since the fence signalled before the first waiter returns, I'd say that's at least sort of correct. :)
I agree that it is 'sort of' correct. But a program that is very particular
about fence being reached within set time-out period or not will misbehave.

>=> r600_fence_reference and st_client_wait_sync continue working
>   with the fence object memory, which was already freed by thread
>   1.

I see that, since so->fence is duplicated at the beginning of the function,
destruction of the fence object would never happen in the block covered by
cmpxchg. If it ever happens then that would be by the 'unref' before the
function exit.

> Did you run into any particular problem with my latest patch?
I run my app for while with your patch minus the locking during reference
duplication and observed no crashes. I'm sufficiently confident that yours is
correct and my remaining concern is mostly about lock contention plus the
feeling that solution via serialization of unref-ops blurs the nature of the
problem that is inherent in the sock code. There is also a concern that if you
acquire lock during reference duplication here, someone who study this part of
the code later on may think that locking is necessary operation and do the same
even though reference duplication is, as far as I can see, lock-free operation.
That would further increase contention.
With all that said, I don't mind you applying your patch to the master. I
believe it is correct. Your decision must take priority because I think you are
in position to devote much more time and energy in improving mesa than I can
contribute. In addition, I would not be enough confident about my cmpxchg
solution until I write tens of unit-tests to be run days and weeks continuously
in various environments, which I perhaps will not have time for.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161025/c6eb1ebe/attachment.html>