From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11186 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.comp.gdb.patches,gmane.linux.lib.musl.general Subject: Re: [musl] Re: [PATCH] Fix invalid sigprocmask call Date: Fri, 24 Mar 2017 11:35:30 -0400 Message-ID: <20170324153530.GF17319@brightrain.aerifal.cx> References: <1490324519-11228-1-git-send-email-yszhou4tech@gmail.com> <2b0bab84-e36e-e109-5444-dc84369dddce@redhat.com> <39f28782-65e8-0f52-3c8f-134a6f05788b@redhat.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1490369747 18885 195.159.176.226 (24 Mar 2017 15:35:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Mar 2017 15:35:47 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Pedro Alves , gdb-patches@sourceware.org, musl@lists.openwall.com To: Yousong Zhou Original-X-From: gdb-patches-return-137802-gdb-gdb-patches=m.gmane.org@sourceware.org Fri Mar 24 16:35:41 2017 Return-path: Envelope-to: gdb-gdb-patches@m.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crRFX-0003rL-SN for gdb-gdb-patches@m.gmane.org; Fri, 24 Mar 2017 16:35:36 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=IOJL 2nNbePRrqbQYgzY7B1sePDhmip3/yPRr3HETaaCcdyMGV3uC9TSUyBCmfBYPe0f3 NTxEWIcAbiUKu8G1vey5XhqZyOTcJfOmQfjH5Gz53kmQudIQNuMELKBhy+Iicjcs bnSdqFsBDG86xNuG0YHBkJJnYp1nQg04xtynwiE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=dsZiWBzWCv yY1HDePy3Uz1flh9M=; b=J+le0aGoBzlxVnN58VbJXOqI/mb74dHxgQumN6CYco 0aPml/k4Bjo3mgdwjhMzVTkL+kU7+CRCrVJZOBnIXW5xs7xvYr2F7roP+jjrEQeL SAtORlW0gm+Eo15N6onLroHmc4713uU7mqOZJJJSCsbI/1nenExUbsWrCkGV5X+7 g= Original-Received: (qmail 19201 invoked by alias); 24 Mar 2017 15:35:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: gdb-patches-owner@sourceware.org Original-Received: (qmail 19188 invoked by uid 89); 24 Mar 2017 15:35:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: brightrain.aerifal.cx Original-Received: from 216-197-64-233.tingfiber.com (HELO brightrain.aerifal.cx) (216.197.64.233) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Mar 2017 15:35:33 +0000 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1crRFS-000712-00; Fri, 24 Mar 2017 15:35:30 +0000 Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.comp.gdb.patches:122758 gmane.linux.lib.musl.general:11186 Archived-At: On Fri, Mar 24, 2017 at 09:05:15PM +0800, Yousong Zhou wrote: > On 24 March 2017 at 20:55, Pedro Alves wrote: > > On 03/24/2017 12:23 PM, Yousong Zhou wrote: > >> On 24 March 2017 at 18:47, Pedro Alves wrote: > >>> On 03/24/2017 03:01 AM, Yousong Zhou wrote: > >>>> The POSIX document says > >>>> > >>>> The pthread_sigmask() and sigprocmask() functions shall fail if: > >>>> > >>>> [EINVAL] > >>>> The value of the how argument is not equal to one of the defined values. > >>>> > >>>> and this is how musl-libc is currently doing. Fix the call to be safe > >>>> and correct > >>>> > >>>> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_sigmask.html > >>>> > >>> > >>> I don't agree. It's a musl bug. Please fix it / file a musl bug. > >> > >> I already did that before sending to gdb-patches > >> > >> http://www.openwall.com/lists/musl/2017/03/24/1 > >> > >> I am aware of the fact that the current code works with glibc and mac > >> osx 10.11.6. The Linux kernel code at the moment also accepts the > >> call with how==0 > > > > Cool. > > > >> > >> But this is more about interpretation of POSIX document itself. And > >> it says, clearly without pre-condition words or ambiguity in the > >> ERRORS section of that page, to return EINVAL if how is not equal to > >> one of the defined values. > > > > The standard wasn't built on a vacuum. It starts by ratifying common > > implementation behavior. If no historical implementation behaves like what > > you're suggesting, what's the point of enforcing that, when it's clearly > > NOT the intent? You're just causing porting pain for no good reason. > > Please file a bug against the standard to have the error section clarified instead. > > Lol, now I will consider the idea of bumping the door of POSIX committee ;) If you file a report and it's deemed a bug in the standard and changed, I'm happy to change this on the musl side. Just keep me posted on what happens. I don't have any preference on what the behavior "should" be here (IMO imposing a behavior when the caller has violated constraints like passed a wrong value for how is pointless anyway) but I do want to conform to the standard. > >> I also tried to find some posix-compliant testsuite and to search the > >> github code for samples of pthread_sigmask call. The first I came > >> across was the following code snippet at link > >> https://github.com/juj/posixtestsuite/blob/master/conformance/interfaces/pthread_sigmask/8-1.c#L57 > >> > >> pthread_sigmask(SIG_BLOCK, NULL, &oactl); > > > > The fact that that call includes SIG_BLOCK doesn't say whether > > passing 0 should be rejected. > > > > So I cloned that repo, and did a quick grep. And lo: > > > > https://github.com/juj/posixtestsuite/blob/26372421f53aeeeeeb4b23561c417886f1930ef6/conformance/interfaces/fork/12-1.c#L187 > > > > /* Examine the current blocked signal set. USR1 & USR2 shall be present */ > > ret = sigprocmask( 0, NULL, &mask ); > > > > if ( ret != 0 ) > > { > > UNRESOLVED( errno, "Sigprocmask failed in child" ); > > } > > > > Thanks, > > Pedro Alves > > > > Okay, then another fact that the posixtestsuite project also expects > to accept how==0 > > I am cc-ing musl-libc list now. If you're talking about "Open POSIX Test Suite", which the above link seems to point to a fork of, the majority of its tests are invalid, invoking undefined behavior then asserting that the error/effect they wrongly expect happens. Without a thorough audit of its test validity it's less than worthless. Rich