This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/21778] Robust mutex may deadlock
- From: "triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 24 Jul 2017 21:08:22 +0000
- Subject: [Bug nptl/21778] Robust mutex may deadlock
- Auto-submitted: auto-generated
- References: <bug-21778-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21778
--- Comment #5 from Torvald Riegel <triegel at redhat dot com> ---
Thanks for the bug report and the analysis. This bug was probably introduced
by me when fixing another robust mutex bug in
65810f0ef05e8c9e333f17a44e77808b163ca298; I believe this happened when changing
C11 atomics back to old-style atomics (which don't update the expected value
when they fail, whereas C11 CAS does).
I think there is a simpler fix, but I haven't tested this one yet:
--- a/nptl/pthread_mutex_lock.c
+++ b/nptl/pthread_mutex_lock.c
@@ -197,11 +197,14 @@ __pthread_mutex_lock_full (pthread_mutex_t *mutex)
{
/* Try to acquire the lock through a CAS from 0 (not acquired) to
our TID | assume_other_futex_waiters. */
- if (__glibc_likely ((oldval == 0)
- && (atomic_compare_and_exchange_bool_acq
- (&mutex->__data.__lock,
- id | assume_other_futex_waiters, 0) == 0)))
- break;
+ if (__glibc_likely (oldval == 0))
+ {
+ oldval
+ = atomic_compare_and_exchange_val_acq (&mutex->__data.__lock,
+ id | assume_other_futex_waiters, 0);
+ if (__glibc_likely (oldval == 0))
+ break;
+ }
if ((oldval & FUTEX_OWNER_DIED) != 0)
{
(and similar for timed locks).
This updates oldval, so further branches don't run with oldval==0.
Carlos, this is likely a regression. Is this still eligible for this release?
If so, I'd try to build a testsuite-ready test case based on the one posted
here, and post upstream tomorrow.
--
You are receiving this mail because:
You are on the CC list for the bug.