mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
To: musl@lists.openwall.com
Subject: Re: [musl] race condition in sem_wait
Date: Wed, 19 Feb 2020 09:26:30 +0100	[thread overview]
Message-ID: <706da236-bee2-eb6d-9dcb-f55c2b69b6e6@dd-wrt.com> (raw)
In-Reply-To: <20200219033952.GA1663@brightrain.aerifal.cx>


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


Sebastian

>
> Rich
>

  reply	other threads:[~2020-02-19  8:26 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 [this message]
2020-02-19 14:13             ` Rich Felker
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=706da236-bee2-eb6d-9dcb-f55c2b69b6e6@dd-wrt.com \
    --to=s.gottschall@dd-wrt.com \
    --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).