Re: [PATCH 2/2] mips: Remove rt_sigreturn usage on context function

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Mon, 3 Jun 2019, Adhemerval Zanella wrote:

> >  This is an obsolete interface, but FYI according to the relevant version 
> > of SUS[1] you are supposed to be able to return from a signal handler by 
> > calling setcontext(3) similarly to siglongjmp(3) and by removing this code 
> > you make the context not to be fully restored in that case (on the MIPS 
> > target the distinction is due to the DSP register state).
> > 
> >  What do you mean by: "setcontext is not async-signal-safe"?  I think such 
> > an assertion (if indeed true) should have been explained in the commit 
> > message even if it was previously discussed (where?).
> 
> It is in fact blurry on POSIX 2001, since it defines on '3. Definitions' [1] that
> function *is not* async-cancel-safe unless explicitly described as such and
> later on '2.4 Signal Concepts' [2] it defines the function set that should be
> async-signal-safe and it does not list 'setcontext' as one.

 Well, it says specifically that:

"[An async-cancel-safe function is] A function that may be invoked, 
without restriction, from signal-catching functions."

which in my opinion does not preclude a non-async-cancel-safe function to 
be called with some restrictions.  And the description of the function 
clearly states it is intended to be used in a signal handler.  So while we 
may not be required by the standard to produce a predictable result, we 
certainly are allowed to if feasible.

 NB `siglongjmp' isn't listed as an async-cancel-safe function either and 
I think we have no doubt as to whether it can be called in a signal 
handler and produce a predictable result.

> It is even more complicated because this is not portable over architectures on
> Linux, since:
> 
>     1. not every one supports rt_sigaction. It means that either that architecture
>        does not really require additional context that userland might not
>        save/restore or that architecture extensions save/restore are not really 
>        supported.
>        For instance, it seems that newer architectures (like RiscV) follow this
>        approach and just really support synchronous by saving/restore the preserved
>        state. It is the same with some newer ABI extension, such as AArch64 SVE.
> 
>     2. Not every architecture passes an mcontext_t and third argument for signal
>        handlers with SA_SIGINFO (sparc and ia64 for instance). 
> 
>     3. Even for architecture that does support passing an mcontext_t, userland
>        can not have enough information that some context is lazy-saved (such some
>        architecture extension such as vector register) by the kernel.
> 
> So that's why I think setcontext is not really aync-signal-safe and it is really
> hard to get it right in Linux (check powerpc complexity over time to support 
> Altivec and later VSX) and while it is support is very architecture-specific.  

 Perhaps Power would have to define and use a set of syscalls to aid the 
userland in selecting the set of registers to save and restore.  It was 
proposed for the MIPS/Linux port too, but it turned out unnecessary.

 I see no need or sense to remove what used to just work.

> I am not really against reverting the patch, and it might be better outcome for an 
> already deprecated symbol, but my idea was to make it somewhat more sane and 
> portable on Linux.

 In what sense portable?

  Maciej