From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id dd772ef2 for ; Wed, 19 Feb 2020 03:42:43 +0000 (UTC) Received: (qmail 16160 invoked by uid 550); 19 Feb 2020 03:42:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14263 invoked from network); 19 Feb 2020 03:40:05 -0000 Date: Tue, 18 Feb 2020 22:39:52 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200219033952.GA1663@brightrain.aerifal.cx> References: <543bcfcc-41f8-6960-8b6a-8e7fd5f01a01@adelielinux.org> <20200218222325.la2lz2yiny6rm47u@gentoo-zen2700x> <8a85b4ac-e1ed-dc30-bdad-b1e33ed20257@newmedia-net.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8a85b4ac-e1ed-dc30-bdad-b1e33ed20257@newmedia-net.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] race condition in sem_wait 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). Rich