[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 #43 from Michel Dänzer <michel at daenzer.net> ---
(In reply to Suzuki, Shinji from comment #41)
> "screen->fence_reference(screen, &fence, NULL);
> is thread-safe if calls are serialized otherwise not thread safe".

Not quite.

 screen->fence_reference(screen, &fence, NULL);

is always thread-safe with a local variable fence, because each thread has a
separate instance of the local variable, so only one of them will attempt to
destroy the fence object referenced by the pointer stored in the local
variables.


(In reply to Suzuki, Shinji from comment #42)
> (The use of the shared completion flag seems to have potential
> synchronization problem because a waiter can see a successful wait as a
> result of unsuccessful call to fence_finish() if another thread comes and
> completes a successful fence_finish() call after the first thread completes
> unsuccessful fence_finish() but before returns.)

Since the fence signalled before the first waiter returns, I'd say that's at
least sort of correct. :)


>    screen->fence_reference(screen, &fence, so->fence);

[...]

>    if (fence) {
>       if(screen->fence_finish(screen, fence, timeout)) {
>          so->b.StatusFlag = GL_TRUE;
>          if( p_atomic_cmpxchg(&so->fence, fence, NULL) == fence ) {

I'm afraid there's still a race here:

Thread 0                                                            Thread 1
--------                                                            --------

screen->fence_reference(screen, &fence, so->fence);
-> struct r600_multi_fence *rsrc = (struct r600_multi_fence *)src;
   -> rsrc != NULL

                                                                    if
(p_atomic_cmpxchg(&so->fence, fence, NULL) == fence) {
                                                                    -> fence !=
NULL, so->fence == NULL
                                                                       ->
continues to destroy the fence object

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


Did you run into any particular problem with my latest patch? Assuming the
shared mutex contention is your only issue with it, have you actually measured
any significant contention with it? If not, I'd like to submit it as the fix
for this bug report. It can always be changed to use a per-fence-object mutex
later if somebody measures significant contention with the shared mutex.

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