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: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: sigaltstack breaks swapcontext()
Date: Thu, 7 Jan 2016 22:10:21 +0300	[thread overview]
Message-ID: <568EB81D.9030209@list.ru> (raw)
In-Reply-To: <CALCETrWKCOBj12cv7LVPOrATKG9UqC1kJbP5SjCYFoXXw=qyLw@mail.gmail.com>

07.01.2016 20:23, Andy Lutomirski пишет:
> On Thu, Jan 7, 2016 at 7:33 AM, Stas Sergeev <stsp@list.ru> wrote:
>> 06.01.2016 22:53, Andy Lutomirski пишет:
>>> On Wed, Jan 6, 2016 at 11:31 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>> Exactly.
>>>> Do you think this can be ignored?
>>>> A man page should then be corrected with EPERM and the
>>>> above note removed, right?
>>>>
>>> I think it can be ignored.  I'd go the SS_FORCE route, though, to
>>> maintain POSIX compliance.
>> I think such a flag would be a wrong thing to do.
>> Allowing only SS_DISABLE (without any new flags) keeps
>> you still "compatible with posix", and anything beyond
>> SS_DISABLE in a sighandler is not needed.
>>
>> So I think we only have the following options:
>> 1. Remove the check and forget (if anything, glibc can
>> add the EPERM check to stay compatible with crap).
>> 2. Allow only SS_DISABLE. This will mean a large patch,
>> touching all arches, but the bonus is the compatibility
>> with posix, that no one needs in this particular case.
> Why does allowing SS_DISABLE require touching all arches?
I mean, if we also consistently return SA_ONSTACK even
after SS_DISABLE. This will require kernel to save the
ss_flags separately, and not to use "if (ss_size)" checks.
Of course if we don't want to return SA_ONSTACK, we
should just remove EPERM as I don't think it serves any
other purpose than that.

  reply	other threads:[~2016-01-07 19:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06 15:45 sigaltstack breaks swapcontext() Stas Sergeev
2016-01-06 18:05 ` Andy Lutomirski
2016-01-06 18:42   ` Stas Sergeev
2016-01-06 19:14     ` Andy Lutomirski
2016-01-06 19:31       ` Stas Sergeev
2016-01-06 19:53         ` Andy Lutomirski
2016-01-07 15:33           ` Stas Sergeev
2016-01-07 17:23             ` Andy Lutomirski
2016-01-07 19:10               ` Stas Sergeev [this message]
2016-01-08 13:49   ` Stas Sergeev
2016-01-08 23:24     ` Andy Lutomirski
2016-01-08 23:40       ` Stas Sergeev
2016-01-09  1:43       ` Stas Sergeev
2016-01-09  1:48         ` Andy Lutomirski
2016-03-07 20:02           ` Stas Sergeev
2016-03-07 21:10             ` Andy Lutomirski
2016-03-07 21:20               ` Stas Sergeev
2016-03-07 21:32                 ` Andy Lutomirski
2016-03-07 21:38                   ` One Thousand Gnomes
2016-03-07 21:45                   ` 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=568EB81D.9030209@list.ru \
    --to=stsp@list.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /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).