Re: [musl] Revisiting sigaltstack and implementation-internal signals

[Ariadne Conill <ariadne@dereferenced.org>]

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.

Ariadne