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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 31/05/2019 23:22, Maciej W. Rozycki wrote:
> On Wed, 17 Apr 2019, Adhemerval Zanella wrote:
> 
>> If no one opposes I will commit this shortly.
>>
>> On 15/02/2019 12:11, Adhemerval Zanella wrote:
>>> Similar to powerpc, mips also issues rt_sigreturn for setcontext
>>> case the v0 value saved is not the one set by setcontext or
>>> makecontext. As for powerpc, it is intention is no really supported
>>> since setcontext is not async-signal-safe.
> 
>  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.

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.  

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.

As a side node, should we move these symbols to deprecated status?

[1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html
[2] http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

> 
> References:
> 
> [1] <http://pubs.opengroup.org/onlinepubs/009695399/functions/setcontext.html>
> 
>   Maciej
>