|
Message-ID: <c06792ad-859d-5514-96fe-c97564596fe5@newmedia-net.de> Date: Wed, 19 Feb 2020 00:29:33 +0100 From: Sebastian Gottschall <s.gottschall@...media-net.de> To: musl@...ts.openwall.com Subject: race condition in sem_wait 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? Sebastian
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.