From: walter harms <wharms@bfs.de>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Stas Sergeev <stsp@list.ru>,
linux-man <linux-man@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Oleg Nesterov <oleg@redhat.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Documenting sigaltstack SS_AUTODISRM
Date: Mon, 30 Oct 2017 11:21:45 +0100 [thread overview]
Message-ID: <59F6FD39.40502@bfs.de> (raw)
In-Reply-To: <a5565692-7f23-d236-3b01-142088310741@gmail.com>
Am 30.10.2017 11:04, schrieb Michael Kerrisk (man-pages):
> [So, things fell on the floor, a while back.]
>
> On 05/25/2017 11:17 AM, Stas Sergeev wrote:
>> 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
>>> One could do this I suppose, but I read POSIX differently from
>>> you and, more importantly, SS_ONSTACK breaks portability on
>>> numerous other systems and is a no-op on Linux. So, the Linux man
>>> page really should warn against its use in the strongest terms.
>> So how about instead of the strongest terms towards
>> the code's author, just explain that SS_ONSTACK is a
>> bit-value on some/many OSes, and as such, 0 is a
>> valid value to enable sas on them, plus all the other
>> values would give EINVAL?
>> No strongest terms will help w/o an explanation,
>> because people will keep looking for something that
>> suits as a missing SS_ENABLE.
>
> Fair enough. I've removed the statement in the manual page
> about "confusion". By now the page says:
>
> BUGS
> In the lead up to the release of the Linux 2.4 kernel, a change
> was made to allow sigaltstack() to accept SS_ONSTACK in
> ss.ss_flags, which results in behavior that is the same as when
> ss_flags is 0 (i.e., the inclusion of SS_ONSTACK in ss.ss_flags is
> a no-op). On other implementations, and according to POSIX.1,
i am confused, i understand that:
ss.ss_sp = malloc(SIGSTKSZ);
ss.ss_size = SIGSTKSZ;
ss.ss_flags = 0;
if (sigaltstack(&ss, NULL) == -1)
is equivalent to:
ss.ss_sp = malloc(SIGSTKSZ);
ss.ss_size = SIGSTKSZ;
ss.ss_flags = SS_ONSTACK ;
if (sigaltstack(&ss, NULL) == -1)
but also to
ss.ss_sp = malloc(SIGSTKSZ);
ss.ss_size = SIGSTKSZ;
ss.ss_flags = SS_ONSTACK | SOMETHING_FLAG ;
if (sigaltstack(&ss, NULL) == -1)
so the use of SS_ONSTACK would result in ss.ss_flags = 0 no matter what.
OR
SS_ONSTACK is a no-op in Linux
re,
wh
> SS_ONSTACK appears only as a reported flag in old_ss.ss_flags. On
> Linux, there is no need ever to specify this flag in ss.ss_flags,
> and indeed doing so should be avoided on portability grounds: var‐
> ious other systems give an error if SS_ONSTACK is specified in
> ss.ss_flags.
>
> Cheers,
>
> Michael
>
next prev parent reply other threads:[~2017-10-30 10:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 20:38 Documenting sigaltstack SS_AUTODISRM Michael Kerrisk (man-pages)
2017-05-22 20:38 ` Michael Kerrisk (man-pages)
2017-05-22 23:36 ` Stas Sergeev
[not found] ` <08467ae1-7187-3b2a-9a78-8af0c10bf816-cmBhpYW9OiY@public.gmane.org>
2017-05-23 10:35 ` Michael Kerrisk (man-pages)
2017-05-23 10:35 ` Michael Kerrisk (man-pages)
[not found] ` <3907bc2a-0645-8d93-6ee5-3f99874e7022-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-05-23 11:03 ` Stas Sergeev
2017-05-23 11:03 ` Stas Sergeev
[not found] ` <32d95303-5839-9279-a1d3-a06f34e3484e-cmBhpYW9OiY@public.gmane.org>
2017-05-23 12:26 ` Michael Kerrisk (man-pages)
2017-05-23 12:26 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgw6P5RAsA2RSFJX57b=DHM=eNZ+ZOoagcO3ydSHzBcQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-23 23:01 ` Stas Sergeev
2017-05-23 23:01 ` Stas Sergeev
2017-05-24 11:09 ` Michael Kerrisk (man-pages)
[not found] ` <026308b5-4e92-4439-1eb2-82b67584d548-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-05-24 20:12 ` Stas Sergeev
2017-05-24 20:12 ` Stas Sergeev
[not found] ` <6f622987-9517-ee7c-2016-ea8c43645e39-cmBhpYW9OiY@public.gmane.org>
2017-10-30 12:38 ` Michael Kerrisk (man-pages)
2017-10-30 12:38 ` Michael Kerrisk (man-pages)
[not found] ` <b87af49f-230b-30d6-fa9b-adaa75ebab52-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-06 22:26 ` Michael Kerrisk (man-pages)
2017-11-06 22:26 ` Michael Kerrisk (man-pages)
[not found] ` <be8a3232-f90e-1bf6-794c-d4a29541c437-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-06 22:28 ` Stas Sergeev
2017-11-06 22:28 ` Stas Sergeev
[not found] ` <22a30d19-3ecb-3d7d-8a86-59b35e057554-cmBhpYW9OiY@public.gmane.org>
2017-11-08 7:41 ` Michael Kerrisk (man-pages)
2017-11-08 7:41 ` Michael Kerrisk (man-pages)
2017-05-25 9:17 ` Stas Sergeev
2017-05-25 9:17 ` Stas Sergeev
[not found] ` <3a4f9f3e-fc33-cf98-2322-27087664813f-cmBhpYW9OiY@public.gmane.org>
2017-10-30 10:04 ` Michael Kerrisk (man-pages)
2017-10-30 10:04 ` Michael Kerrisk (man-pages)
2017-10-30 10:21 ` walter harms [this message]
[not found] ` <59F6FD39.40502-fPG8STNUNVg@public.gmane.org>
2017-10-30 10:50 ` Michael Kerrisk (man-pages)
2017-10-30 10:50 ` Michael Kerrisk (man-pages)
2017-10-30 10:58 ` Stas Sergeev
2017-10-30 12:54 ` walter harms
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=59F6FD39.40502@bfs.de \
--to=wharms@bfs.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mtk.manpages@gmail.com \
--cc=oleg@redhat.com \
--cc=stsp@list.ru \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.