From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13345 Path: news.gmane.org!.POSTED!not-for-mail From: Rabbitstack Newsgroups: gmane.linux.lib.musl.general Subject: Re: setrlimit hangs the process Date: Tue, 9 Oct 2018 21:37:06 +0200 Message-ID: References: <20180925141551.GE10209@port70.net> <20180925153605.GF10209@port70.net> <20180925163850.GL17995@brightrain.aerifal.cx> <20181004150421.GC17110@brightrain.aerifal.cx> <20181004155302.GD17110@brightrain.aerifal.cx> <20181005004715.GF17110@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000afa92b0577d0dd0f" X-Trace: blaine.gmane.org 1539113730 3320 195.159.176.226 (9 Oct 2018 19:35:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2018 19:35:30 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-13361-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 09 21:35:25 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 1g9xmu-0000kp-Do for gllmg-musl@m.gmane.org; Tue, 09 Oct 2018 21:35:24 +0200 Original-Received: (qmail 23576 invoked by uid 550); 9 Oct 2018 19:37:32 -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 23554 invoked from network); 9 Oct 2018 19:37:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+32wTH8e32tLJw1OAzhI6UE7buSIEwHOEufQmulZlCE=; b=B8Tw+IYig4aRqfI88pPpwqS50iAopjPw4+t72US+we5qMh4wBJm+QhpslLjWP00AWg 7ChfCA23fFjdx2FlwMSKS5a2gI+wztbMY947yVFOS/oDjG72bVgtZ9fVaqswLoZ6Kilc vQt00qzbiXzwdQAmieS2OP8YalKqaQ1HUDEFD1cev1HoWvs6oR2MhoUmci0xIaIQOKmi FQxnMTfR/RNmo5pbbqMw9Fm5/vL+erUht/TxcjuKSPHFYoW0XvhmKEvxRdZlHGYucHJL G0dBK0y4gjkCMVwUjLrMIUp07r8FLyoheMtjOViJOWlxWGohVHQIFByVA8GVsiXwLl0i pdEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+32wTH8e32tLJw1OAzhI6UE7buSIEwHOEufQmulZlCE=; b=PF8dyXtDYkID/l9Lqxo0QvSlAepUjttdQSkU4FB+TIWH4dTlt8cKPn1uLnnf5O72aV IT+JVzTc4NqgSU5PsyiNYSWfBCy8nrogC/wUPxATn9n5Br7Zm3am3k1V3vWR/wtNP9qX jRaA3mFQZcACYSmBUrshDvwrKJcSAshJqUGYao1j47YT4pvViVZAhx3Ltle+liX5c3ul mUOKfEBDvYAG2vtjaOaT4ePE91ZjNR0gf2jbZVu0TAH1z4drjmPDZ4M6B9OSsFeTuUZg Y3ZyiAJ0AGpyDNe61y5i7dG0uJfvcVniFM98iJ3K+Ikxcxjo8O3y2SiZ0RuqUHSsQtWS JjKQ== X-Gm-Message-State: ABuFfogaIhKKQp1Hk9qMU1XEiP8AVK0YY/59bZRB3KYcXACZ29cSrFBL 9qXOQ86SmKu22/l1p4WGTh4z6TIkNg1uztjOxA== X-Google-Smtp-Source: ACcGV60f8FDUE02pJcvhhk8dMby6lOTY9i8IR12A1PiiEP4TJ7SCsLUTnfz6HL8swxue86I3CC5fa2XhH0lkSDuEcaA= X-Received: by 2002:a62:3995:: with SMTP id u21-v6mr31732156pfj.116.1539113839731; Tue, 09 Oct 2018 12:37:19 -0700 (PDT) In-Reply-To: <20181005004715.GF17110@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13345 Archived-At: --000000000000afa92b0577d0dd0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Should we raise an issue in Go upstream repository since there is nothing actionable from musl side? El vie., 5 oct. 2018 2:47, Rich Felker escribi=C3=B3: > On Thu, Oct 04, 2018 at 11:53:02AM -0400, Rich Felker wrote: > > On Thu, Oct 04, 2018 at 05:41:52PM +0200, Rabbitstack wrote: > > > Please use the following link to download strace since daemon is > refusing > > > to deliver the mail. > > > > > > https://www.dropbox.com/s/syhbzxvijf7s4v1/agent.strace?dl=3D0 > > > > Here is the bug: > > > > 6208 rt_sigprocmask(SIG_SETMASK, ~[HUP INT QUIT ILL TRAP ABRT BUS FPE > SEGV TERM STKFLT CHLD PROF SYS RTMIN RT_1], > > > > Apparently Go has its own version of sigfillset, rather than calling > > the libc one, and it's hard-coded the glibc values for which signals > > are reserved for the implementation (just RTMIN and RT_1) rather than > > honoring SIGRTMIN (which resolves at runtime via a function call), > > which would exempt RT_2 from being blocked too. > > > > It needs to be fixed on the Go side. I'll look at it later if nobody > > else more familiar with Go gets to it sooner. > > If these are the right source files: > > https://golang.org/src/runtime/os_linux_generic.go#L33 > https://golang.org/src/runtime/sys_linux_amd64.s#L290 > > Then they're not even making any attempt to avoid stomping on > implementation-internal signals, and there's nothing musl could do to > prevent this. This suggests to me that something in your codebase is > explicitly avoiding RTMIN and RT_1 (33 and 34). Making it also avoid > RT_2 (35) would be a short-term hack you could use to get past this > problem, but there's no guarantee assignments won't change in the > future (this is why SIGRTMIN and SIGRTMAX macros expand to functions > calls). Really if a Go program wants to use libc, it needs to avoid > bypassing libc in ways that change the process state (like signal mask > or disposition). > > Rich > --000000000000afa92b0577d0dd0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0Should we raise an issue in Go upstream repository = since there is nothing actionable from musl side?=C2=A0

El vie., 5 oct. 2018 2:47, Rich Felker &l= t;dalias@libc.org> escribi=C3=B3:=
On Thu, Oct 04, 2018 at 11:53:02AM= -0400, Rich Felker wrote:
> On Thu, Oct 04, 2018 at 05:41:52PM +0200, Rabbitstack wrote:
> > Please use the following link to download strace since=C2=A0 daem= on is refusing
> > to deliver the mail.
> >
> > https://www.dropbo= x.com/s/syhbzxvijf7s4v1/agent.strace?dl=3D0
>
> Here is the bug:
>
> 6208=C2=A0 rt_sigprocmask(SIG_SETMASK, ~[HUP INT QUIT ILL TRAP ABRT BU= S FPE SEGV TERM STKFLT CHLD PROF SYS RTMIN RT_1],=C2=A0 <unfinished ...&= gt;
>
> Apparently Go has its own version of sigfillset, rather than calling > the libc one, and it's hard-coded the glibc values for which signa= ls
> are reserved for the implementation (just RTMIN and RT_1) rather than<= br> > honoring SIGRTMIN (which resolves at runtime via a function call),
> which would exempt RT_2 from being blocked too.
>
> It needs to be fixed on the Go side. I'll look at it later if nobo= dy
> else more familiar with Go gets to it sooner.

If these are the right source files:

https://golang.org/src/runtime/os_l= inux_generic.go#L33
https://golang.org/src/runtime/sys_l= inux_amd64.s#L290

Then they're not even making any attempt to avoid stomping on
implementation-internal signals, and there's nothing musl could do to prevent this. This suggests to me that something in your codebase is
explicitly avoiding RTMIN and RT_1 (33 and 34). Making it also avoid
RT_2 (35) would be a short-term hack you could use to get past this
problem, but there's no guarantee assignments won't change in the future (this is why SIGRTMIN and SIGRTMAX macros expand to functions
calls). Really if a Go program wants to use libc, it needs to avoid
bypassing libc in ways that change the process state (like signal mask
or disposition).

Rich
--000000000000afa92b0577d0dd0f--