Messages in this thread | | | Date | Mon, 1 Feb 2016 20:29:36 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 4/4] sigaltstack: allow disabling and re-enabling sas within sighandler |
| |
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.
| |