From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128057 invoked by alias); 24 Mar 2017 12:55:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 128039 invoked by uid 89); 24 Mar 2017 12:55:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=vacuum, mac, Hx-languages-length:2360, clarified X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Mar 2017 12:55:33 +0000 Received: by mail-wr0-f176.google.com with SMTP id l43so1148051wre.1 for ; Fri, 24 Mar 2017 05:55:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=13TdDiMldxkOC83KV2Tkixajjk7Cj9KJ4rV0h+9kF0Q=; b=or/pR/OMaEvRRaojc+GIIlJgF0AxBCDkF5cuH0exZZh4pg8z9IIS1Q/VtBldNdpQ7w 4C6iv1fUGWhnD2sTQ88DHsMgC31bmnheUbIXykGi1xjstasT+4NEb5hUPpPU1Ns/K7N3 3j71ERAEBFh1Ku21hKSWw9GvhuYdsL6aSrZvHT1Dt1eRWMX3Yk4qs6As6PN6oaosKe3E LiDyg4K3YzZOaaNBjj+lIjZmpuc1qR7NqOicRav0W8gMJb2og2BMomS9Up6W+oJYxEUn JSinSGnK+mKROfNuJ82ayNqmQSRhITgjWb+K0mxCZXNYx0qOWsoknvrkHCJhVbbS3nhy qMUg== X-Gm-Message-State: AFeK/H3li5n8HscsmYa9K9TVhTOntBVIRsHBa2Ih8lAJSAu/Ue4bR7GxJrYfIYEdGy1iCdnl X-Received: by 10.223.165.74 with SMTP id j10mr7153708wrb.143.1490360132045; Fri, 24 Mar 2017 05:55:32 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id b42sm2820321wra.36.2017.03.24.05.55.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 05:55:31 -0700 (PDT) Subject: Re: [PATCH] Fix invalid sigprocmask call To: Yousong Zhou References: <1490324519-11228-1-git-send-email-yszhou4tech@gmail.com> <2b0bab84-e36e-e109-5444-dc84369dddce@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <39f28782-65e8-0f52-3c8f-134a6f05788b@redhat.com> Date: Fri, 24 Mar 2017 12:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00436.txt.bz2 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. > > 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