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 21591 invoked from network); 3 Mar 2021 14:43:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Mar 2021 14:43:51 -0000 Received: (qmail 30080 invoked by uid 550); 3 Mar 2021 14:43:45 -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 30058 invoked from network); 3 Mar 2021 14:43:45 -0000 Date: Wed, 3 Mar 2021 09:43:32 -0500 From: Rich Felker To: Jesse Hathaway Cc: musl@lists.openwall.com Message-ID: <20210303144332.GL32655@brightrain.aerifal.cx> References: <20200929183644.GE17637@brightrain.aerifal.cx> <20200929203407.GH17637@brightrain.aerifal.cx> <20200930001001.GI17637@brightrain.aerifal.cx> <20200930155547.GA4436@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, Mar 03, 2021 at 08:40:57AM -0600, Jesse Hathaway wrote: > On Wed, Sep 30, 2020 at 10:55 AM 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. > > Unfortunately I failed to submit a bug report for this issue. However, the > bug was reported by someone else and fixed with this commit: > > commit 49b017fe59bf628795f2c4fdbcb5db942e865fa9 > Author: George Tsilias > Date: Thu Jun 4 23:11:56 2020 +0300 > > runtime: handle signal 34 for musl setgid > > It has been observed that setgid hangs when using cgo with musl. > This fix ensures that signal 34 gets handled in an appropriate way, > like signal 33 when using glibc. > > Fixes #39343 > > Unfortunately, it did not use sigaddset as you suggested, but instead hard-coded > the signal: > > diff --git a/src/runtime/sigtab_linux_generic.go > b/src/runtime/sigtab_linux_generic.go > index b26040b803..38d686544f 100644 > --- a/src/runtime/sigtab_linux_generic.go > +++ b/src/runtime/sigtab_linux_generic.go > @@ -45,7 +45,7 @@ var sigtable = [...]sigTabT{ > /* 31 */ {_SigThrow, "SIGSYS: bad system call"}, > /* 32 */ {_SigSetStack + _SigUnblock, "signal 32"}, /* > SIGCANCEL; see issue 6997 */ > /* 33 */ {_SigSetStack + _SigUnblock, "signal 33"}, /* > SIGSETXID; see issues 3871, 9400, 12498 */ > - /* 34 */ {_SigNotify, "signal 34"}, > + /* 34 */ {_SigSetStack + _SigUnblock, "signal 34"}, /* musl > SIGSYNCCALL; see issue 39343 */ > /* 35 */ {_SigNotify, "signal 35"}, > /* 36 */ {_SigNotify, "signal 36"}, > /* 37 */ {_SigNotify, "signal 37"}, > diff --git a/src/runtime/sigtab_linux_mipsx.go > b/src/runtime/sigtab_linux_mipsx.go > index 81dd2314c5..51ef470ce7 100644 > --- a/src/runtime/sigtab_linux_mipsx.go > +++ b/src/runtime/sigtab_linux_mipsx.go > @@ -42,7 +42,7 @@ var sigtable = [...]sigTabT{ > /* 31 */ {_SigNotify, "SIGXFSZ: file size limit exceeded"}, > /* 32 */ {_SigSetStack + _SigUnblock, "signal 32"}, /* > SIGCANCEL; see issue 6997 */ > /* 33 */ {_SigSetStack + _SigUnblock, "signal 33"}, /* > SIGSETXID; see issues 3871, 9400, 12498 */ > - /* 34 */ {_SigNotify, "signal 34"}, > + /* 34 */ {_SigSetStack + _SigUnblock, "signal 34"}, /* musl > SIGSYNCCALL; see issue 39343 */ > /* 35 */ {_SigNotify, "signal 35"}, > /* 36 */ {_SigNotify, "signal 36"}, > /* 37 */ {_SigNotify, "signal 37"}, Anyone want to submit a bug report for this (the signal numbers are not public or stable) or should I make a note to do it? Rich