From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] race condition in sem_wait
Date: Wed, 19 Feb 2020 09:13:35 -0500 [thread overview]
Message-ID: <20200219141335.GF1663@brightrain.aerifal.cx> (raw)
In-Reply-To: <706da236-bee2-eb6d-9dcb-f55c2b69b6e6@dd-wrt.com>
On Wed, Feb 19, 2020 at 09:26:30AM +0100, Sebastian Gottschall wrote:
>
> Am 19.02.2020 um 04:39 schrieb Rich Felker:
> >On Wed, Feb 19, 2020 at 01:46:34AM +0100, Sebastian Gottschall wrote:
> >>Hello
> >>
> >>i discovered recently a race condition while playing with threads
> >>and sem_wait/sem_post
> >>sem_wait may fail with errno set EAGAIN which is not valid since
> >>only sem_trywait is able to set that errno code.
> >>this was causing a bug with a later select() and accept() which
> >>failed since accept does not work if errno is set to EAGAIN.
> >>from my point of view the bug is in sem_timedwait.c
> >>
> >> if (!sem_trywait(sem)) return 0;
> >>
> >> int spins = 100;
> >> while (spins-- && sem->__val[0] <= 0 && !sem->__val[1]) a_spin();
> >>
> >> while (sem_trywait(sem)) {
> >>
> >>
> >>the fist sem_trywait will fail with -1 and sets EAGAIN. but the
> >>second sem_trywait will not fail and does return 0. the problem now
> >>is that errno is still present and not reset.
> >>this may cause if sem_post is called from a second thread on the
> >>same semaphore.
> >>of course the same bug affects sem_timedwait itself.
> >>so i assume sem_wait is not thread safe which is bad and is not
> >>follow the posix specification
> >>
> >>or am i wrong here?
> >errno is only meaningful on failure; unless specified otherwise (a few
> >functions are special because you can't [easily] distinguish success
> >from failure for them without examining errno), any standard function
> >may have changed the value of errno when it returns with success. The
> >only thing it's not allowed to do is clear it (set it to 0).
> the problem is the posix manual specifies exclicit that EAGAIN
> cannot be returned by sem_wait and in my code sample
>
> the following happens
>
> sem_wait(semaphort)
> select(....)
> socket = accept(....) -> fails
>
> accept fails because sem_wait did set errno to EAGAIN and accept
> will fail if errno is set to EAGAIN
> i use sem_wait to limit the number of threads in my webserver. on
> the thread itself i call sem_post.
> but to make it work correct i have to set errno=0 before calling
> accept since accept will not work if errno is set to EAGAIN
> if you read the posix man for accept, you will find out that accept
> will read errno unconditional and this is also the case for the musl
> implementation
accept does not use errno as input. Unless I'm forgetting something,
no interfaces in libc except perror, syslog (%m), and *printf (%m
extension) use errno as input. If accept is failing (returning -1)
with errno==EAGAIN it's not because errno was EAGAIN before you called
it but because your listening socket is in non-blocking mode and there
is no pending connection to accept.
Rich
next prev parent reply other threads:[~2020-02-19 14:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 19:38 [musl] Locale support considered harmful noise Jacob Welsh
2020-02-18 21:42 ` A. Wilcox
2020-02-18 22:23 ` Hadrien Lacour
2020-02-18 23:29 ` [musl] race condition in sem_wait Sebastian Gottschall
2020-02-19 0:46 ` Sebastian Gottschall
2020-02-19 3:39 ` Rich Felker
2020-02-19 8:26 ` Sebastian Gottschall
2020-02-19 14:13 ` Rich Felker [this message]
2020-02-19 4:07 ` Bobby Bingham
2020-02-19 21:28 ` [musl] Locale support considered harmful noise Jacob Welsh
2020-02-19 22:06 ` Rich Felker
2020-02-19 3:36 ` Rich Felker
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=20200219141335.GF1663@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).