Re: [PATCH 4/4] sigaltstack: allow disabling and re-enabling sas within sighandler

On 02/01, Stas Sergeev wrote:

01.02.2016 22:29, Oleg Nesterov пишет:

quoted

quoted

quoted

sigaltstack({ DISABLE | FORCE}, &old_ss);
swapcontext();
sigaltstack(&old_ss, NULL);
rt_sigreturn();

and if you are going to return from sighandler you do not even need the 2nd
sigaltstack(), you can rely on sigreturn.

Yes, that's what I do in my app already.
But its only there when SA_SIGINFO is used.

Hmm. how this connects to SA_SIGINFO ?

AFAIK without SA_SIGINFO you get sigreturn instead of
rt_sigreturn, which doesn't seem to do restore_altstack().
Or am I wrong?

Hmm:

        /* Set up the stack frame */
        if (is_ia32_frame()) {
                if (ksig->ka.sa.sa_flags & SA_SIGINFO)
                        return ia32_setup_rt_frame(usig, ksig, cset, regs);
                else
                        return ia32_setup_frame(usig, ksig, cset, regs);

Ah, ia32... So this is even more confusing.

quoted

quoted

quoted

quoted

What's at the end? Do we want a surprise for the user
that he's new_sas got ignored?

Can't understand.... do you mean "set up new_sas" will be ignored because
rt_sigreturn() does restore_sigaltstack() ? I see no problem here...

Allowing the modifications that were previously EPERMed
but will now be silently ignored, may be seen as a problem.
But if it isn't - fine, lets code that.

Still can't understand. The 2nd sigaltstack() is no longer EPERMed because
application used SS_FORCED before that and disabled altstack.

And it is not ignored, it actually changes alt stack. Until we return from
handler.

Before we return, the signals are usually blocked.
So whatever is after return is most important.

Yes, but I still can't understand your "silently ignored". At least how does
this differ from the case when a non-SA_ONSTACK signal handler does
sigaltstack() and then rt_sigreturn() restores the old stack.

Oleg.