[Bug nptl/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing

["malteskarupke at fastmail dot fm" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25847

--- Comment #21 from Malte Skarupke <malteskarupke at fastmail dot fm> ---
Sorry, I continue to have very little energy to work on this. I have been
putting a little more work into it yesterday though, and I have more doubts now
that the mitigation patch is a long term solution.

I still think it's better than doing nothing, but it might introduce an even
more rare deadlock instead. It's even more rare, because while the current
deadlock triggers only in an edge case of an edge case, the new one would only
trigger in an edge case of said edge case of an edge case.

My suspicions come from trying to make one of the alternative solutions
mentioned in the patch email chain work, which was to do something similar to
the mitigation patch, but to signal for the correct group instead of
broadcasting. I couldn't make that alternative change work, and I reduced the
problem down to calling this right in front of the "We potentially stole a
signal" check:

  __condvar_acquire_lock (cond, private);
  __condvar_release_lock (cond, private);

Just taking and releasing the internal lock can deadlock in some of the tests.
(most often in sysdeps/pthread/tst-cond16.c) The mitigation patch will call
these functions. Most of the time that doesn't deadlock, and I haven't found
out what exactly causes the deadlock (I'll instead put my limited energy back
into a second version of my emailed patch), but the fact that unconditionally
calling the above will deadlock should give us suspicion that calling the above
conditionally might also sometimes deadlock. It's impossible to reproduce in
the glibc tests because it's even more rare than the original problem, so I
think the mitigation patch is still a little better than doing nothing.

Otherwise I think the patch I emailed is still good, (unlike my patch attached
to this issue) and I aim to have a second version out, maybe on the weekend,
that addresses the comments in the email conversation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.