From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932525AbdJ3KFG (ORCPT ); Mon, 30 Oct 2017 06:05:06 -0400 Received: from mail-wr0-f169.google.com ([209.85.128.169]:51919 "EHLO mail-wr0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932315AbdJ3KFE (ORCPT ); Mon, 30 Oct 2017 06:05:04 -0400 X-Google-Smtp-Source: ABhQp+RRN1EWnNa6c/Hs1O0tUGbsiL0rE6e/S8B2asXjMt8TAzIDxNwVJaKKnYOZj9/p0t0aHl68SA== Cc: mtk.manpages@gmail.com, linux-man , Andy Lutomirski , Oleg Nesterov , lkml Subject: Re: Documenting sigaltstack SS_AUTODISRM To: Stas Sergeev References: <08467ae1-7187-3b2a-9a78-8af0c10bf816@list.ru> <3907bc2a-0645-8d93-6ee5-3f99874e7022@gmail.com> <32d95303-5839-9279-a1d3-a06f34e3484e@list.ru> <50de8f3b-8a1e-df50-b5dd-d1b74cb77fad@list.ru> <026308b5-4e92-4439-1eb2-82b67584d548@gmail.com> <3a4f9f3e-fc33-cf98-2322-27087664813f@list.ru> From: "Michael Kerrisk (man-pages)" Message-ID: Date: Mon, 30 Oct 2017 11:04:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3a4f9f3e-fc33-cf98-2322-27087664813f@list.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [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, 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 -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/