linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@list.ru>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Richard Weinberger <richard@nod.at>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Jason Low <jason.low2@hp.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
	Josh Triplett <josh@joshtriplett.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Aleksa Sarai <cyphar@cyphar.com>,
	"Amanieu d'Antras" <amanieu@gmail.com>,
	Paul Moore <pmoore@redhat.com>,
	Sasha Levin <sasha.levin@oracle.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Vladimir Davydov <vdavydov@parallels.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Stas Sergeev <stsp@users.sourceforge.net>
Subject: Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag
Date: Sun, 6 Mar 2016 23:17:16 +0300	[thread overview]
Message-ID: <56DC904C.2060708@list.ru> (raw)
In-Reply-To: <CALCETrW=M1=n6R6dwOj-ks_=+14vf4rz0S3SFty-_GuwFFZU5A@mail.gmail.com>

06.03.2016 23:10, Andy Lutomirski пишет:
> On Sun, Mar 6, 2016 at 12:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev <stsp@list.ru> wrote:
>>> This patch implements the SS_AUTODISARM flag that can be ORed with
>>> SS_ONSTACK when forming ss_flags.
>>> When this flag is set, sigaltstack will be disabled when entering
>>> the signal handler; more precisely, after saving sas to uc_stack.
>>> When leaving the signal handler, the sigaltstack is restored by
>>> uc_stack.
>>> When this flag is used, it is safe to switch from sighandler with
>>> swapcontext(). Without this flag, the subsequent signal will corrupt
>>> the state of the switched-away sighandler.
>>>
>>> CC: Ingo Molnar <mingo@redhat.com>
>>> CC: Peter Zijlstra <peterz@infradead.org>
>>> CC: Richard Weinberger <richard@nod.at>
>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>> CC: Oleg Nesterov <oleg@redhat.com>
>>> CC: Tejun Heo <tj@kernel.org>
>>> CC: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>> CC: Jason Low <jason.low2@hp.com>
>>> CC: Andrea Arcangeli <aarcange@redhat.com>
>>> CC: Frederic Weisbecker <fweisbec@gmail.com>
>>> CC: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>>> CC: Josh Triplett <josh@joshtriplett.org>
>>> CC: "Eric W. Biederman" <ebiederm@xmission.com>
>>> CC: Aleksa Sarai <cyphar@cyphar.com>
>>> CC: "Amanieu d'Antras" <amanieu@gmail.com>
>>> CC: Paul Moore <pmoore@redhat.com>
>>> CC: Sasha Levin <sasha.levin@oracle.com>
>>> CC: Palmer Dabbelt <palmer@dabbelt.com>
>>> CC: Vladimir Davydov <vdavydov@parallels.com>
>>> CC: linux-kernel@vger.kernel.org
>>> CC: linux-api@vger.kernel.org
>>> CC: Andy Lutomirski <luto@amacapital.net>
>>>
>>> Signed-off-by: Stas Sergeev <stsp@users.sourceforge.net>
>>> ---
>>>   include/linux/sched.h       |  8 ++++++++
>>>   include/linux/signal.h      |  4 +++-
>>>   include/uapi/linux/signal.h |  3 +++
>>>   kernel/fork.c               |  2 +-
>>>   kernel/signal.c             | 23 ++++++++++++-----------
>>>   5 files changed, 27 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>> index a10494a..26201cd 100644
>>> --- a/include/linux/sched.h
>>> +++ b/include/linux/sched.h
>>> @@ -1587,6 +1587,7 @@ struct task_struct {
>>>
>>>          unsigned long sas_ss_sp;
>>>          size_t sas_ss_size;
>>> +       unsigned sas_ss_flags;
>>>
>>>          struct callback_head *task_works;
>>>
>>> @@ -2573,6 +2574,13 @@ static inline int sas_ss_flags(unsigned long sp)
>>>          return on_sig_stack(sp) ? SS_ONSTACK : 0;
>>>   }
>>>
>>> +static inline void sas_ss_reset(struct task_struct *p)
>>> +{
>>> +       p->sas_ss_sp = 0;
>>> +       p->sas_ss_size = 0;
>>> +       p->sas_ss_flags = SS_DISABLE;
>>> +}
>>> +
>>>   static inline unsigned long sigsp(unsigned long sp, struct ksignal *ksig)
>>>   {
>>>          if (unlikely((ksig->ka.sa.sa_flags & SA_ONSTACK)) && ! sas_ss_flags(sp))
>>> diff --git a/include/linux/signal.h b/include/linux/signal.h
>>> index 92557bb..3fbe814 100644
>>> --- a/include/linux/signal.h
>>> +++ b/include/linux/signal.h
>>> @@ -432,8 +432,10 @@ int __save_altstack(stack_t __user *, unsigned long);
>>>          stack_t __user *__uss = uss; \
>>>          struct task_struct *t = current; \
>>>          put_user_ex((void __user *)t->sas_ss_sp, &__uss->ss_sp); \
>>> -       put_user_ex(sas_ss_flags(sp), &__uss->ss_flags); \
>>> +       put_user_ex(t->sas_ss_flags, &__uss->ss_flags); \
>>>          put_user_ex(t->sas_ss_size, &__uss->ss_size); \
>>> +       if (t->sas_ss_flags & SS_AUTODISARM) \
>>> +               sas_ss_reset(t); \
>>>   } while (0);
>>>
>>>   #ifdef CONFIG_PROC_FS
>>> diff --git a/include/uapi/linux/signal.h b/include/uapi/linux/signal.h
>>> index e1bd50c2..4691bc5 100644
>>> --- a/include/uapi/linux/signal.h
>>> +++ b/include/uapi/linux/signal.h
>>> @@ -6,5 +6,8 @@
>>>
>>>   #define SS_ONSTACK     1
>>>   #define SS_DISABLE     2
>>> +#define SS_VALMASK     0xf
>> SS_MODE_MASK, perhaps?
> Actually, let's invert that.
>
> #define SS_AUTODISARM (1U << 31)
> #define SS_FLAG_BITS SS_AUTODISARM
>
> ss_mode = ss_flags & ~SS_FLAG_BITS;
>
> this way flag bits that are currently undefined will continue to trigger EINVAL.
OK, will do.
Though I am still going to keep SS_AUTODISARM =(1 << 4) -
it doesn't matter from what side we add new flags, does it?

  reply	other threads:[~2016-03-06 20:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 21:29 [PATCH v4 0/2] make sigaltstack() compatible with swapcontext() Stas Sergeev
2016-02-29 21:29 ` [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag Stas Sergeev
2016-03-04 22:22   ` Andy Lutomirski
2016-03-05  7:39     ` Stas Sergeev
2016-03-05  7:40       ` Stas Sergeev
2016-03-06 20:07   ` Andy Lutomirski
2016-03-06 20:10     ` Andy Lutomirski
2016-03-06 20:17       ` Stas Sergeev [this message]
2016-03-06 20:55         ` Andy Lutomirski
2016-02-29 21:29 ` [PATCH 2/2] selftests: Add test for sigaltstack(SS_AUTODISARM) Stas Sergeev
2016-03-06 20:02 ` [PATCH v4 0/2] make sigaltstack() compatible with swapcontext() Szabolcs Nagy
2016-03-06 20:27   ` Stas Sergeev
2016-03-06 20:27   ` Szabolcs Nagy
  -- strict thread matches above, loose matches on Subject: below --
2016-02-28 21:13 [PATCH v3 " Stas Sergeev
2016-02-28 21:13 ` [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag Stas Sergeev
2016-02-29  6:29   ` 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=56DC904C.2060708@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=fweisbec@gmail.com \
    --cc=jason.low2@hp.com \
    --cc=josh@joshtriplett.org \
    --cc=khlebnikov@yandex-team.ru \
    --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=sasha.levin@oracle.com \
    --cc=stsp@users.sourceforge.net \
    --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).