From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 5AF8622E1D for ; Mon, 19 Feb 2024 12:17:43 +0100 (CET) Received: (qmail 11837 invoked by uid 550); 19 Feb 2024 11:14:26 -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 26332 invoked from network); 19 Feb 2024 10:57:37 -0000 Date: Mon, 19 Feb 2024 14:00:33 +0300 From: Valery Ushakov To: Rich Felker Cc: musl@lists.openwall.com Message-ID: References: <349f4e17-8027-c521-eeb3-aa69e8f2b5a4@landley.net> <20240218013428.GJ4163@brightrain.aerifal.cx> <20240218014049.GK4163@brightrain.aerifal.cx> <20240218143312.GL4163@brightrain.aerifal.cx> <20240218203306.GM4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240218203306.GM4163@brightrain.aerifal.cx> Subject: Re: [musl] Re: Not sure how to debug this one. On Sun, Feb 18, 2024 at 15:33:06 -0500, Rich Felker wrote: > > Restoring the context in siglongjmp should not be a problem per-se. > > NetBSD libc does that and the example code doesn't crash there (quick > > unscientific test on a ppc that I happen to have a terminal open on). > > But then NetBSD libc doesn't bother to carefully factor that code to > > minimize the need for MD asm. > > > > Thanks, and sorry for the noise. > > If you restore the signal mask from the returning context rather than > in the returned-to context, there's always the possibility of stack > overflow; in the worst case, this happens on the sigaltstack where > you're specifically taking measures to avoid stack overflow being a > fatal error. The test program is artificial, but the real-world way > this would happen is getting a flood of signals like SIGINT or SIGTSTP > or something coming in faster than you can respond to them, so that > every time you try to return via siglongjmp, you actually consume > another stack frame on the signal stack. > > If NetBSD didn't crash, maybe it just has a much larger default stack > size limit? Or maybe they reload sp before calling sigprocmask? That > would work too, but the reason musl doesn't do it that way is that our > setjmp/longjmp are compatible with an old ABI where there is no extra > space in the jmp_buf for sigjmp_buf stuff. As luck would have it, powerpc was doing the right thing. We filed a bug to fix the arches that don't. Thanks! -uwe