01.02.2016 23:41, Oleg Nesterov пишет:

On 02/01, Stas Sergeev wrote:

quoted

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

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.

There is quite a difference.
It is very-very unlikely that non-SA_ONSTACK signal handler does 
sigaltstack().
I think only the test-case could exhibit this.
But with SS_FORCE - most of every SS_FORCE user will be
trapped, because, as you mentioned, not many know about
uc_stack. My patch was allowing them to do only what is safe:
just as it was without a patch.
But anyway, I'll be implementing SS_FORCE because 2 people
have voted.