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=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 23917e8d for ; Wed, 19 Feb 2020 12:00:02 +0000 (UTC) Received: (qmail 1232 invoked by uid 550); 19 Feb 2020 11:59:59 -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 15838 invoked from network); 18 Feb 2020 23:29:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=newmedia-net.de; s=mikd; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=1bcoJrMJvPp7UWUsvPg2DFub307vUy5KdoRl2mSHFvk=; b=kVqlnpifJXbbqV38/iDNe2OLx+MCmEC+m8yoiEkV5exTdazttcjdumZpimIVsnHGZmHVi3vpvu8K5PaBd+R3WJ6dWKmeIQt9gL8n0EdcUfqxC8DTFnzbQ+adJK4he3YAdEU5eiY5vMv73bPe9xwkoDRdQnTOKXl+dHYmOXMJRfo=; To: musl@lists.openwall.com References: <543bcfcc-41f8-6960-8b6a-8e7fd5f01a01@adelielinux.org> <20200218222325.la2lz2yiny6rm47u@gentoo-zen2700x> From: Sebastian Gottschall Message-ID: Date: Wed, 19 Feb 2020 00:29:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200218222325.la2lz2yiny6rm47u@gentoo-zen2700x> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Received: from [2a01:7700:8040:a100:5044:e4be:9cc3:3abb] by webmail.newmedia-net.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1j4CGd-0003y0-6l for musl@lists.openwall.com; Wed, 19 Feb 2020 00:27:03 +0100 Subject: [musl] 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