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 9868 invoked from network); 10 Aug 2020 00:06:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2020 00:06:40 -0000 Received: (qmail 1294 invoked by uid 550); 10 Aug 2020 00:06:35 -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 1275 invoked from network); 10 Aug 2020 00:06:35 -0000 Date: Sun, 9 Aug 2020 20:06:22 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200810000622.GF3265@brightrain.aerifal.cx> References: <20200809003958.GE3265@brightrain.aerifal.cx> <20200809075430.GA10312@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200809075430.GA10312@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Revisiting sigaltstack and implementation-internal signals On Sun, Aug 09, 2020 at 09:54:31AM +0200, 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(). My understanding is that SA_ONSTACK is just reported by the kernel if the current stack pointer is inside the alternate stack. If the application has moved off that stack and a signal arrives, it has nowhere to know "where in the alternate stack it was" or that the alternate stack was even already in use, and clobbers it from the beginning if a new signal arrives that is to execute on the alternate stack. If you think this understanding is incorrect, we should research/test. Rich