Date:	Mon, 1 Feb 2016 22:46:12 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Linux kernel <linux-kernel@...r.kernel.org>,
	linux-api@...r.kernel.org, Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Amanieu d'Antras <amanieu@...il.com>,
	Richard Weinberger <richard@....at>, Tejun Heo <tj@...nel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Jason Low <jason.low2@...com>,
	Heinrich Schuchardt <xypron.glpk@....de>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
	Josh Triplett <josh@...htriplett.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Aleksa Sarai <cyphar@...har.com>,
	Paul Moore <pmoore@...hat.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Vladimir Davydov <vdavydov@...allels.com>
Subject: Re: [PATCH 4/4] sigaltstack: allow disabling and re-enabling sas
 within sighandler

01.02.2016 22:29, Oleg Nesterov пишет:
> 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.
OK.

> 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.
OK.

>>> 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 ?
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);
         } else if (is_x32_frame()) {
                 return x32_setup_rt_frame(ksig, cset, regs);
         } else {
                 return __setup_rt_frame(ksig->sig, ksig, set, regs);
         }



>>>> 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.

Powered by blists - more mailing lists