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 12329 invoked from network); 10 Aug 2020 00:26:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2020 00:26:51 -0000 Received: (qmail 13877 invoked by uid 550); 10 Aug 2020 00:26: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 13859 invoked from network); 10 Aug 2020 00:26:44 -0000 Date: Sun, 9 Aug 2020 20:26:32 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200810002632.GG3265@brightrain.aerifal.cx> References: <20200809003958.GE3265@brightrain.aerifal.cx> <20200809075430.GA10312@voyager> <1dff31ba-0e68-dca3-5cfc-22e254190799@dereferenced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1dff31ba-0e68-dca3-5cfc-22e254190799@dereferenced.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Revisiting sigaltstack and implementation-internal signals On Sun, Aug 09, 2020 at 06:10:02PM -0600, Ariadne Conill wrote: > Hello, > > On 2020-08-09 01:54, Markus Wichmann wrote: > >On Sat, Aug 08, 2020 at 08:39:58PM -0400, Rich Felker wrote: > >>on it (possibly not even any signal handlers installed), and (2) > >>whether we should care about breaking code that swaps off of and back > >>onto the alternate signal stack with swapcontext. > > > >Would anything bad happen in that case? I thought, when a signal handler > >with SA_ONSTACK is invoked, the altstack is marked with SS_ONSTACK and > >will not be reset until the signal handler returns. If the handler does > >not return, and does not call sigaltstack(), then the SS_ONSTACK remains > >set, and therefore further signals with SA_ONSTACK will be delivered on > >the current stack. Otherwise, if a signal were to arrive while the > >altstack is in use, it would overwrite the old stack. > > > >I cannot find a source code for swapcontext, but to my knowledge it > >merely combines setjmp() and longjmp(), right? (setjmp() for the current > >context and longjmp() for the other one). So no call to sigaltstack(). > > musl itself does not ship the ucontext.h functions, to get them > users must install my libucontext library. > > libucontext does not make use of setjmp/longjmp or sigaltstack. For > the most part we just provide a simple context-swapping > implementation in assembly, except on POWER where we just wrap the > SYS_swapcontext syscall. > > So any behavior change with sigaltstack() should not effect > libucontext behavior in theory. The question is not about the behavior of the ucontext implementation but of applications which use the API or do equivalent context-switch things. Rich