On 02/01, Stas Sergeev wrote:
>
> 01.02.2016 21:52, Oleg Nesterov пишет:
> >Stas, I probably missed something, but I don't understand your concerns,
> >
> >On 02/01, Stas Sergeev wrote:
> >>01.02.2016 21:04, Oleg Nesterov пишет:
> >>>Yes, and SS_FORCE means "I know what I do", looks very simple.
> >>But to me its not because I don't know what to do with
> >>uc_stack after SS_FORCE is applied.
> >Nothing? restore_sigaltstack() should work as expected?
> That's likely the reason for EPERM: restore_sigaltstack()
> does the job, so manual modifications are disallowed.
> Allowing them will bring in the surprises where the changes
> done by the user are ignored.
Unlikely. Suppose you do sigalstack() and then a non SA_ONSTACK signal handler
runs and calls sigaltstack() again. This won't fail, but restore_sigaltstack()
will restore the old alt stack after return.
I too do not know why uc_stack exists, in fact I do not know about it until
today when I read your patch ;) But it is here, and I do not think SS_FORCE
can add more confusion than we already have.
> >Yes, or
> >
> > 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 ?
> >>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.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
