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

[Rich Felker <dalias@libc.org>]

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