From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH v2] fix race condition in file locking
Date: Tue, 18 Sep 2018 11:55:08 -0400 [thread overview]
Message-ID: <20180918155508.GV17995@brightrain.aerifal.cx> (raw)
In-Reply-To: <20180918070327.32154-1-kaarle.ritvanen@datakunkku.fi>
On Tue, Sep 18, 2018 at 10:03:27AM +0300, Kaarle Ritvanen wrote:
> The condition occurs when
> - thread #1 is holding the lock
> - thread #2 is waiting for it on __futexwait
> - thread #1 is about to release the lock and performs a_swap
> - thread #3 enters the __lockfile function and manages to grab the lock
> before thread #1 calls __wake, resetting the MAYBE_WAITERS flag
> - thread #1 calls __wake
> - thread #2 wakes up but goes again to __futexwait as the lock is
> held by thread #3
> - thread #3 releases the lock but does not call __wake as the
> MAYBE_WAITERS flag is not set
>
> This condition results in thread #2 not being woken up. This patch fixes
> the problem by making the woken up thread ensure that the flag is
> properly set before going to sleep again.
> ---
> src/stdio/__lockfile.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/stdio/__lockfile.c b/src/stdio/__lockfile.c
> index 2ff75d8a..0dcb2a42 100644
> --- a/src/stdio/__lockfile.c
> +++ b/src/stdio/__lockfile.c
> @@ -8,13 +8,13 @@ int __lockfile(FILE *f)
> int owner = f->lock, tid = __pthread_self()->tid;
> if ((owner & ~MAYBE_WAITERS) == tid)
> return 0;
> - for (;;) {
> - owner = a_cas(&f->lock, 0, tid);
> - if (!owner) return 1;
> - if (a_cas(&f->lock, owner, owner|MAYBE_WAITERS)==owner) break;
> + owner = a_cas(&f->lock, 0, tid);
> + if (!owner) return 1;
> + while ((owner = a_cas(&f->lock, 0, tid|MAYBE_WAITERS))) {
> + if ((owner & MAYBE_WAITERS) ||
> + a_cas(&f->lock, owner, owner|MAYBE_WAITERS)==owner)
> + __futexwait(&f->lock, owner|MAYBE_WAITERS, 1);
> }
> - while ((owner = a_cas(&f->lock, 0, tid|MAYBE_WAITERS)))
> - __futexwait(&f->lock, owner, 1);
> return 1;
> }
>
> --
> 2.14.4
Thanks! I'm applying this with a note added to the commit message
about the source of the regression. I hit the same race today working
on a test case for something else, so I can confirm it occurs in
practice. Distros using musl 1.1.20 should apply this patch.
Rich
prev parent reply other threads:[~2018-09-18 15:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-18 7:03 Kaarle Ritvanen
2018-09-18 15:55 ` Rich Felker [this message]
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=20180918155508.GV17995@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).