From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13512 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: sem_wait and EINTR Date: Thu, 6 Dec 2018 16:57:56 +0100 Message-ID: <20181206155756.GB32233@voyager> References: <20181205191605.72492698@orivej.orivej.org> <20181205194759.GA32233@voyager> <20181205212716.sx6ra2xqhuei735q@core.my.home> <20181205215826.GX23599@brightrain.aerifal.cx> <20181206024340.202e0fc4@orivej.orivej.org> <20181206031756.GZ23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1544111790 26172 195.159.176.226 (6 Dec 2018 15:56:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2018 15:56:30 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13528-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 06 16:56:26 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gUw0i-0006ag-Os for gllmg-musl@m.gmane.org; Thu, 06 Dec 2018 16:56:20 +0100 Original-Received: (qmail 22056 invoked by uid 550); 6 Dec 2018 15:58:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22033 invoked from network); 6 Dec 2018 15:58:29 -0000 Content-Disposition: inline In-Reply-To: <20181206031756.GZ23599@brightrain.aerifal.cx> X-Provags-ID: V03:K1:RblbkyaFqDdjCs6xtQZ3DVCAOeWfVjn8gedYmO3NM2WdFayRdxV CVxO9TMNd9AX3xbzZzljHkv+vXrC32E+xJfor8f+chJp+6HlKN+0phoJ5ok39/X5+wS9UOt OvdzZfjA8E4b0tOMY/+W5CGASzFBiSf5CokHvOxKsIzgtFl8ha/B+KzusyNL8UgLa+uEsDH AYEjZdMJRStQmH7XjaMEA== X-UI-Out-Filterresults: notjunk:1;V03:K0:fgsoB8Toprs=:uDWwFeRT2MaqxqiwEfzTiQ GNY0+IgVrxC7Y89sJ7ZcdlmRHFa+8iSh6lGql8WmmpQnAZZ7mslvlBCuA/qUnkX+nUQGAH3mH vsiTAlOBGJg+lOKIaMFoCLO6+SF9weSw1GiXu4Uvy/Tk9OPSz40vHaZ9yqg2jTOkO3cRCfvZn IbroOhJOOaOtZXYmfwBUREZpvRP1EbzbtOH1jy5+dBqLQcxbi6Thvl/1SFRnb1EfJ4AzVhf6S SDzzGMV7CgLoROchVbdS3A5r0CsO8HLL/PdR3qmQ+6KWDQF9Cmhn/QJ64rCcQlczG1IQRBwMb t64KBRViSihKgRgMa8zHxUIoYXUUC151fxH0+cbMy1SlkGlqHsCc7zBmz90X/xz+PIhzRH2Mh KPwZG/KbMrmn+meApHe4wpQEABWmNWnWgmQ/32Y9GjzpXyGACVm0oeOBzPrcw84CA1A/b/RQs zSTHHTP5le/Ok4e6HhHigRV1TBB22c9UDa8/zZIEC2PUMH4GpmPrYAEkv4gy14aUJQyqowR/t dcP44AlrsVgmBjR6nR6UCqelVF1f1lQuLygAlARa0qe+SRa/+tCzq88toFrAfThySZLIiZ4nb fCYld3T3XZq/51p47mZglGN7p1ma7NmBe4t3Cwzetdp9RkqN6xs7H354zJ8x4yQ7h1m7lW4Ct /sR/Ufl/vcrAvmQQSk+Y4nf4STDnxnUJODDs9ydkVTsAAc9WXtciymFqW+dlJU+mvbDHa3xc/ Dc1N+kQ4NXnNhP8mCcyU32h/sf82+nqerxX2AdINKRu7ozHQeLqZ/a+xumeADzaWBXZ10As5 Xref: news.gmane.org gmane.linux.lib.musl.general:13512 Archived-At: On Wed, Dec 05, 2018 at 10:17:56PM -0500, Rich Felker wrote: > I'd like it if we could avoid the pre-linux-2.6.22 bug of spurious > EINTR from SYS_futex, but I don't see any way to do so except possibly > wrapping all signal handlers and implementing restart-vs-EINTR > ourselves. So if we need to change this, it might just be a case where > we say "well, sorry, your kernel is broken" if someone is using a > broken kernel. > > Thoughts? > > Rich I really don't know what you are getting at, here. In the hypothetical case you detected an EINTR return without a signal having been handled, you could just retry the syscall. The problem is getting that information in the first place. Practically, I see a lot of work for little gain. Wrapping all signal handlers means we need to save up to _NSIG function pointers. Access to those doesn't need serialization any more than sigaction() does. Though, what does it mean if someone changes the signal handler while we are in the wrapper? Due to SA_SIGINFO we'd need two different wrappers. Or we just always set SA_SIGINFO in the kernel. I don't know if that incurs a runtime cost in the kernel, though. On the plus side, restorers would get simpler. Does the "actual signal arrived" bit need to be thread local? And what about race conditions? Well, OK, most races I can think of aren't actually a problem. Any signal arrival between resetting the flag before the syscall and checking it after the syscall would then count. So, all in all we need between 64 and 128 additional machine words in the data section, sigaction() becomes more complicated, all users of __timedwait_cp() become more complicated (you do want to make this behavior consistent, right?), signal handling becomes more complicated over all, and all of that just so that sem_wait() can fail but not under all circumstances. Speaking of calls that shouldn't fail but do: Is futex_wake() affected by the same bug? Ciao, Markus