linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Stas Sergeev <stsp@list.ru>
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 18:27:33 +0100	[thread overview]
Message-ID: <20160201172733.GA20831@redhat.com> (raw)
In-Reply-To: <56AF8E89.5090400@list.ru>

On 02/01, Stas Sergeev wrote:
>
> >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?
> Yes.
> Note: there is a test-case in that patch serie from which
> you can see or copy/paste the sample code.

OK, I wasn't cc'ed

> >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?
> I don't think so. Please see the following hunk:

Yes, see another email, I already noticed this change.

> So I understand this is very confusing, but I think the patch
> is correct.

Not sure, but I can hardly read this patch and I can't apply it.

> Do you think adding the SS_FORCE flag would be a better solution?

Yes, certainly. I see no point to remember that a thread actually has the alt stack
but it was disabled.

Oleg.

  reply	other threads:[~2016-02-01 17:27 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-31 16:16 [PATCH 0/4] make sigaltstack() compatible with swapcontext() Stas Sergeev
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
2016-02-12 16:17     ` Stas Sergeev
2016-01-31 16:21 ` [PATCH 2/4] score: signal: fix sigaltstack check Stas Sergeev
2016-02-02 19:07   ` Lennox Wu
2016-01-31 16:24 ` [PATCH 3/4] x86: signal: unify the sigaltstack check with other arches Stas Sergeev
2016-01-31 16:58   ` Andy Lutomirski
2016-01-31 18:03     ` Stas Sergeev
2016-01-31 16:28 ` [PATCH 4/4] sigaltstack: allow disabling and re-enabling sas within sighandler Stas Sergeev
2016-01-31 17:00   ` Andy Lutomirski
2016-01-31 17:33     ` Stas Sergeev
2016-01-31 19:03       ` Andy Lutomirski
2016-01-31 20:08         ` Stas Sergeev
2016-01-31 20:11           ` Andy Lutomirski
2016-01-31 22:36             ` Stas Sergeev
2016-01-31 22:44               ` Andy Lutomirski
2016-01-31 23:45                 ` Stas Sergeev
2016-02-01 16:06   ` Oleg Nesterov
2016-02-01 16:57     ` Stas Sergeev
2016-02-01 17:27       ` Oleg Nesterov [this message]
2016-02-01 17:09     ` Oleg Nesterov
2016-02-01 17:26       ` Stas Sergeev
2016-02-01 18:04         ` Oleg Nesterov
2016-02-01 18:16           ` Stas Sergeev
2016-02-01 18:28             ` Andy Lutomirski
2016-02-01 18:40               ` Stas Sergeev
2016-02-01 18:52             ` Oleg Nesterov
2016-02-01 19:01               ` Stas Sergeev
2016-02-01 19:29                 ` Oleg Nesterov
2016-02-01 19:46                   ` Stas Sergeev
2016-02-01 20:41                     ` Oleg Nesterov
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
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=20160201172733.GA20831@redhat.com \
    --to=oleg@redhat.com \
    --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=palmer@dabbelt.com \
    --cc=peterz@infradead.org \
    --cc=pmoore@redhat.com \
    --cc=richard@nod.at \
    --cc=stsp@list.ru \
    --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).