From: Stas Sergeev <stsp@list.ru>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>,
linux-api@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Amanieu d'Antras <amanieu@gmail.com>,
Richard Weinberger <richard@nod.at>, Tejun Heo <tj@kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Jason Low <jason.low2@hp.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Andrea Arcangeli <aarcange@redhat.com>,
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
Josh Triplett <josh@joshtriplett.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Aleksa Sarai <cyphar@cyphar.com>, Paul Moore <pmoore@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Vladimir Davydov <vdavydov@parallels.com>
Subject: Re: [PATCH 4/4] sigaltstack: allow disabling and re-enabling sas within sighandler
Date: Mon, 1 Feb 2016 20:26:53 +0300 [thread overview]
Message-ID: <56AF955D.7060601@list.ru> (raw)
In-Reply-To: <20160201170958.GA20735@redhat.com>
01.02.2016 20:09, Oleg Nesterov пишет:
> On 02/01, Oleg Nesterov wrote:
>>> + onsigstack = on_sig_stack(sp);
>>> + if (ss_size == 0) {
>>> + switch (ss_flags) {
>>> + case 0:
>>> + error = -EPERM;
>>> + if (onsigstack)
>>> + goto out;
>>> + current->sas_ss_sp = 0;
>>> + current->sas_ss_size = 0;
>>> + current->sas_ss_flags = SS_DISABLE;
>>> + break;
>>> + case SS_ONSTACK:
>>> + /* re-enable previously disabled sas */
>>> + error = -EINVAL;
>>> + if (current->sas_ss_size == 0)
>>> + goto out;
>>> + break;
>>> + default:
>>> + break;
>>> + }
>> and iiuc the "default" case allows you to write SS_DISABLE into ->sas_ss_flags
>> even if on_sig_stack().
>>
>> So the sequence is
>>
>> // running on alt stack
>>
>> sigaltstack(SS_DISABLE);
>>
>> temporary_run_on_another_stack();
>>
>> sigaltstack(SS_ONSTACK);
>>
>> and SS_DISABLE saves us from another SA_ONSTACK signal, right?
>>
>> But afaics it can only help after we change the stack. Suppose that SA_ONSTACK signal
>> comess before temporary_run_on_another_stack(). get_sigframe() should be fine after
>> your changes (afaics), it won't pick the alt stack after SS_DISABLE.
>>
>> However, unless I missed something save_altstack_ex() will record SS_ONSTACK in
>> uc_stack->ss_flags, and after return from signal handler restore_altstack() will
>> enable alt stack again?
> OK, I didn't notice you modified save_altstack_ex() to use ->sas_ss_flags instead
> of sas_ss_flags()... still doesn't look right, in this case restore_altstack() will
> not restore sas_ss_size/sas_ss_sp and they can be changed by signal handler.
How?
Trying to change them in a sighandler with sigaltstack()
will get EPERM. And if you change them in uc_stack without
setting ss_flags back to SS_ONSTACK, they should better be ignored.
> Anyway, whatever I missed I agree with Andy, SS_FORCE looks simpler and better to me.
But perhaps you missed the most important thing, that
it is not possible to change the altstack in sighandler - you'll
get EPERM, even with my patch. But with SS_FORCE this is
exactly not the case. So I'd like you to confirm your opinion
after all the implementation details are understood.
Also it would be interesting to know what do you think about
just removing the EPERM check instead of this all. There are
3 possibilities to choose from, not 2. Removing EPERM looks
simplest.
next prev parent reply other threads:[~2016-02-01 17:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-31 16:16 [PATCH 0/4] make sigaltstack() compatible with swapcontext() Stas Sergeev
[not found] ` <56AE3369.2090709-cmBhpYW9OiY@public.gmane.org>
2016-01-31 16:18 ` [PATCH 1/4] selftests: Add test for sigaltstack(SS_DISABLE) inside sighandler Stas Sergeev
2016-02-12 16:12 ` Shuah Khan
[not found] ` <56BE046D.4080203-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
2016-02-12 16:17 ` Stas Sergeev
2016-01-31 16:28 ` [PATCH 4/4] sigaltstack: allow disabling and re-enabling sas within sighandler Stas Sergeev
[not found] ` <56AE3626.7080706-cmBhpYW9OiY@public.gmane.org>
2016-01-31 17:00 ` Andy Lutomirski
2016-01-31 17:33 ` Stas Sergeev
[not found] ` <56AE4567.9000403-cmBhpYW9OiY@public.gmane.org>
2016-01-31 19:03 ` Andy Lutomirski
[not found] ` <CALCETrUVODhNRwvbAfC0q3RVJAFw-ZFGhsww2uQsk3UZjLynnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-31 20:08 ` Stas Sergeev
[not found] ` <56AE69AD.6090005-cmBhpYW9OiY@public.gmane.org>
2016-01-31 20:11 ` Andy Lutomirski
[not found] ` <CALCETrXPYLqunBNxjS8bpmpg+jG_MXbSyZtUVK3X3m+pGSQ1Og-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-31 22:36 ` Stas Sergeev
[not found] ` <56AE8C80.6030408-cmBhpYW9OiY@public.gmane.org>
2016-01-31 22:44 ` Andy Lutomirski
[not found] ` <CALCETrU2u7h98oqtMcgvU54j21-bpTfBXUEJNQO9r1w5FHc-HQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-31 23:45 ` Stas Sergeev
2016-02-01 16:06 ` Oleg Nesterov
[not found] ` <20160201160625.GA18276-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-02-01 16:57 ` Stas Sergeev
[not found] ` <56AF8E89.5090400-cmBhpYW9OiY@public.gmane.org>
2016-02-01 17:27 ` Oleg Nesterov
2016-02-01 17:09 ` Oleg Nesterov
2016-02-01 17:26 ` Stas Sergeev [this message]
2016-02-01 18:04 ` Oleg Nesterov
[not found] ` <20160201180443.GA21064-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-02-01 18:16 ` Stas Sergeev
[not found] ` <56AFA0E2.1030302-cmBhpYW9OiY@public.gmane.org>
2016-02-01 18:28 ` Andy Lutomirski
[not found] ` <CALCETrWv87BS5hH20qKd7WGuf6EAEb4f78Myq+6fqXgSJWoiew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-01 18:40 ` Stas Sergeev
2016-02-01 18:52 ` Oleg Nesterov
[not found] ` <20160201185223.GA21136-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-02-01 19:01 ` Stas Sergeev
2016-02-01 19:29 ` Oleg Nesterov
[not found] ` <20160201192936.GA21214-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-02-01 19:46 ` Stas Sergeev
2016-02-01 20:41 ` Oleg Nesterov
[not found] ` <20160201204114.GA21638-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-02-01 23:06 ` Stas Sergeev
-- strict thread matches above, loose matches on Subject: below --
2016-01-31 19:10 [PATCH v2 0/4] make sigaltstack() compatible with swapcontext() Stas Sergeev
[not found] ` <56AE5C08.6010403-cmBhpYW9OiY@public.gmane.org>
2016-01-31 19:18 ` [PATCH 4/4] sigaltstack: allow disabling and re-enabling sas within sighandler Stas Sergeev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56AF955D.7060601@list.ru \
--to=stsp@list.ru \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=amanieu@gmail.com \
--cc=cyphar@cyphar.com \
--cc=ebiederm@xmission.com \
--cc=jason.low2@hp.com \
--cc=josh@joshtriplett.org \
--cc=khlebnikov@yandex-team.ru \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pmoore@redhat.com \
--cc=richard@nod.at \
--cc=tj@kernel.org \
--cc=vdavydov@parallels.com \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).