|
Message-ID: <87mu9f9q3p.fsf@koorogi.info> Date: Tue, 18 Feb 2020 22:07:54 -0600 From: Bobby Bingham <koorogi@...rogi.info> To: musl@...ts.openwall.com Subject: Re: race condition in sem_wait Sebastian Gottschall <s.gottschall@...media-net.de> writes: > 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. Whether select/accept work or not should not be impacted by any existing value in errno. > 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 To quote POSIX [1]: The value of errno should only be examined when it is indicated to be valid by a function's return value. [...] The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified. If sem_wait() returns zero, then the value in errno after the call returns is not meaningful in any way. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html > > or am i wrong here? > > > Sebastian Bobby
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.