From: Florian Weimer <fweimer@redhat.com>
To: Torvald Riegel <triegel@redhat.com>,
GLIBC Devel <libc-alpha@sourceware.org>
Cc: vl@samba.org, Michael Adam <madam@redhat.com>,
Rich Felker <dalias@libc.org>
Subject: Re: [PATCH][BZ #20973] Robust mutexes: Fix lost wake-up.
Date: Fri, 16 Dec 2016 14:11:00 -0000 [thread overview]
Message-ID: <7415d701-9dab-3c99-2716-2dcd3a4ac731@redhat.com> (raw)
In-Reply-To: <1481840946.14990.588.camel@redhat.com>
On 12/15/2016 11:29 PM, Torvald Riegel wrote:
> Assume that Thread 1 waits to acquire a robust mutex using futexes to
> block (and thus sets the FUTEX_WAITERS flag), and is unblocked when this
> mutex is released. If Thread 2 concurrently acquires the lock and is
> killed, Thread 1 can recover from the died owner but fail to restore the
> FUTEX_WAITERS flag. This can lead to a Thread 3 that also blocked using
> futexes at the same time as Thread 1 to not get woken up because
> FUTEX_WAITERS is not set anymore.
>
> The fix for this is to ensure that we continue to preserve the
> FUTEX_WAITERS flag whenever we may have set it or shared it with another
> thread. This is the same requirement as in the algorithm for normal
> mutexes, only that the robust mutexes need additional handling for died
> owners and thus preserving the FUTEX_WAITERS flag cannot be done just in
> the futex slowpath code.
Description and change look good to me in general.
> [BZ #20973]
> * nptl/pthread_mutex_lock.c (__pthread_mutex_lock_full): Fix lost
> wake-up in robust mutexes.
> * nptl/pthread_mutex_timedlock.c (pthread_mutex_timedlock): Likewise.
>
> diff --git a/nptl/pthread_mutex_lock.c b/nptl/pthread_mutex_lock.c
> index bdfa529..01ac75e 100644
> --- a/nptl/pthread_mutex_lock.c
> +++ b/nptl/pthread_mutex_lock.c
> @@ -182,6 +182,11 @@ __pthread_mutex_lock_full (pthread_mutex_t *mutex)
> &mutex->__data.__list.__next);
>
> oldval = mutex->__data.__lock;
> + /* This is set to FUTEX_WAITERS iff we might have shared the
âiffâ doesn't seem to be correct here because it's not an exact
equivalence, âifâ is sufficient.
> + FUTEX_WAITERS flag with other threads, and therefore need to keep it
> + set to avoid lost wake-ups. We have the same requirement in the
> + simple mutex algorithm. */
> + unsigned int assume_other_futex_waiters = 0;
> do
> {
> again:
> @@ -190,9 +195,9 @@ __pthread_mutex_lock_full (pthread_mutex_t *mutex)
> /* The previous owner died. Try locking the mutex. */
> int newval = id;
> #ifdef NO_INCR
> - newval |= FUTEX_WAITERS;
> + newval |= FUTEX_WAITERS | assume_other_futex_waiters;
> #else
> - newval |= (oldval & FUTEX_WAITERS);
> + newval |= (oldval & FUTEX_WAITERS) | assume_other_futex_waiters;
> #endif
The NO_INCR change is quite confusing. Perhaps drop it and add a comment?
VL, what is the copyright status of your test case?
Thanks,
Florian
next prev parent reply other threads:[~2016-12-16 14:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-15 22:27 Torvald Riegel
2016-12-15 22:29 ` Torvald Riegel
2016-12-16 14:11 ` Florian Weimer [this message]
2016-12-16 14:45 ` Volker Lendecke
[not found] ` <CAJ+X7mT1cU1_2ON2JZM9oYMP_cak734tkf+PZJeo4MZg1i4gmw@mail.gmail.com>
2016-12-19 17:15 ` Florian Weimer
2016-12-16 22:13 ` Torvald Riegel
2016-12-19 19:47 ` Florian Weimer
2016-12-19 20:30 ` Carlos O'Donell
2016-12-20 15:03 ` Torvald Riegel
2016-12-19 18:20 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7415d701-9dab-3c99-2716-2dcd3a4ac731@redhat.com \
--to=fweimer@redhat.com \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
--cc=madam@redhat.com \
--cc=triegel@redhat.com \
--cc=vl@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).