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.
next prev parent 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).