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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 30882 invoked from network); 9 Aug 2020 07:54:47 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Aug 2020 07:54:47 -0000 Received: (qmail 21930 invoked by uid 550); 9 Aug 2020 07:54:43 -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 21912 invoked from network); 9 Aug 2020 07:54:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1596959671; bh=akNV2KIhBbSSCqXm1GrWRf5D5cJ3WwWvfWNaE3Sr+E8=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=hIbVdxgm7R77TRcf3M1TX936Z/8/P6NPOvkiNfyyMt1zB6rPARMFXfKLVPhnBX5xM zBPdTNX300td5TBLAZKL71B+yF2JDOlTiJLzbnzPt7RKxKaVVxqVS8C0f1wpW3Y3dW Ov3inCenorzNnaFvjeUfxt2MnrbJBaaNtGTuPDac= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Sun, 9 Aug 2020 09:54:31 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200809075430.GA10312@voyager> References: <20200809003958.GE3265@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200809003958.GE3265@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:eEgGGhJPv7QpTV+xJfTbX9LFy1KSdm3rumDNK++rqJubJ1zcLsV F4LuC3JpDbxbT+1LvQKBhERZcvlQ7JU48L79aZ1IakbhBlXwWYPB2Mcr1acF1p1OHG7ob2L bcBk5KanbUAiEnWIADduMWl45woad0fDsqwAYhFpIkL9F+4dZLsFXV3l63qHEUVOVwrhV/v SX6IrL7gdbxiyt0qEa+tg== X-UI-Out-Filterresults: notjunk:1;V03:K0:xfSTEHXenrg=:S91udOYcRlSzZZTXQ/S/EF Gh9hb7QyLGlDw9SS2x42a7PYgThhdC+9f/NVO2fh3B3i2Qhmno+IJfNHhcjeS0A6ZDzVZ/df9 3KGkVsUVlapCou1URLWb7SAz7jqX7Rfj93xERwX+I+KOlVeNElQiAUtRjZamowZRgh2TiLRly 9O30nNGH4fKSbUapvuaGjYXxgZgBcIrhEkf60zKHdE+Zt25JwAdhR/m21Qkj0f2X6swyqRvpe y47Zymy1U74jxfHWZrQ7t1Yq0veJJe2EC6aWTqPhyrmWg0nHXQBGdMepUP2KWv+oLgXL9l0Uf oGmNATTkJF3Fel2+779y33zkaK8OO7B7yyT+Ej0Rgk4m1c6b5yMU5SikBMbJY8hPkSaOxzgsA 59L+1o+f3Q74pxx6xHbmjInuaWgbXY7QbIJZnxi59VNRp25LPiaEe/nO0sxOQlf0Z7hZmBKv7 toL8nx3z7svI6esOR4Pa1x2SPjMAc2i3tBATaRHz9D6JYXVgHVw9Yx8ke9DfyCMS280dLdL8b bQFu2/jK2gOOeeAQ9dHXUDfrpFFdgnwPl2TJi2iurIqHsMHJGmUuR7hQVeRZ9iiLeR9aeky4l vYq/waP3PtNjZPMO7lJ7s2bt9uSucwHMK7OwFM200nreBDIXXB+tWfh5IlYsd+fSRTqyy4hvZ YadOHazAU+mSjJeuDAIb7N4oBYAavnRzv3yFoVuNL8xJMRH3VZGbVolkhzOu7zZjsPc1OvtPo 9KKojMDFNhbElnjSKGSS8tCyP4WbxVk7Ghoo1RxJwgVuPx6X5ldV3rBaUAdBXwP/LPh/UD44D NDziFFO2AxuOcRryF0QuPDignCtw4opgrHw/huVgQQYEwspueq+hnFyXcI/9UCQaWAXWyusf/ LF2RvsdBfnRFV0xTZa6KHAuvKAGxOvgoqi7dIzbECAnAA1DAt6nP0mhIPpF0Y42GOERX6Jdl+ 5JZvJeYAivJUf2jxXmEcH6txeRK6vQXPJOi0WG7Za5aVYir1UdhqTNhLO2FHURqUegQkBq5Ul 6vRyaIka2p2L+c2wjLFgqh4MJ/B29reeD4ZDxy4avSeZOw3W2mzgGKWZ53Wln6Q9SaJ9NNjRH N97Ad51dJr8HFfjgdfS4wJ3+QLgnRnjUnKxZ668eSgfCblgMn4BywirvMtkD08STiPQRha4ss m5D+g7U7ah1T2T6cB+J5Ae4kVrtgB9bdcgt4GbJb6cC2GQiCFo/Uv5lCG+RDXVnpQWx2KgaLA enQulwjcuYmVwydl5 Subject: Re: [musl] Revisiting sigaltstack and implementation-internal signals 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(). Ciao, Markus