All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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.