From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13809 invoked from network); 30 Sep 2020 15:56:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Sep 2020 15:56:03 -0000 Received: (qmail 21937 invoked by uid 550); 30 Sep 2020 15:56:01 -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 21919 invoked from network); 30 Sep 2020 15:56:00 -0000 Date: Wed, 30 Sep 2020 11:55:47 -0400 From: Rich Felker To: Jesse Hathaway Cc: musl@lists.openwall.com Message-ID: <20200930155547.GA4436@brightrain.aerifal.cx> References: <20200929183644.GE17637@brightrain.aerifal.cx> <20200929203407.GH17637@brightrain.aerifal.cx> <20200930001001.GI17637@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: Pending patches for MT-fork stuff On Wed, Sep 30, 2020 at 09:46:12AM -0500, Jesse Hathaway wrote: > On Tue, Sep 29, 2020 at 7:10 PM Rich Felker wrote: > > Here is the offending code: > > > > https://github.com/golang/go/blob/a413908dd064de6e3ea5b8d95d707a532bd3f4c8/src/runtime/signal_unix.go#L866 > > > > It should be calling sigfillset() (from libc) to get the starting > > sigset_t rather than using its own all-one-bits initializer. > > > > There may be other places in the runtime where the same error is made. > > It looks like blockableSig (line 1132) is intended to do something > > here, but has hard-coded (somewhere else) glibc knowledge rather than > > probing via (libc's) sigaddset whether the signal number is valid. > > This might be a preferred point to fix it at. > > Thanks Rich for diving in and investigating the problem on the Go runtime > side. I am happy to open a bug report on the Go side, but I have a couple > of questions. Would you instead prefer to open the report, since you have > a much deeper understanding of the problem and what changes need to > be made than I? However, if you would rather I create the report, are you > okay with me quoting your analysis? Thanks, Jesse Please go ahead with it to the extent that you can, quoting my analysis where it's relevant, and if there's anything unclear I'll try to follow up. Rich