Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC][possible bug] when should SS_AUTODISARM have effect?
To:     Andy Lutomirski <luto@kernel.org>,
        Al Viro <viro@zeniv.linux.org.uk>
Cc:     Ingo Molnar <mingo@kernel.org>,
        Linux API <linux-api@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
References: <20200319021629.GC23230@ZenIV.linux.org.uk>
 <CALCETrULZc+T6MeRwfcf=JGoh0xE0YEsTFeLiB5=zdH8AX+3bg@mail.gmail.com>
From:   stsp <stsp2@yandex.ru>
Message-ID: <4b34bac5-9c1e-c1bb-c033-cd373efc1745@yandex.ru>
Date:   Sun, 22 Mar 2020 01:24:05 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <CALCETrULZc+T6MeRwfcf=JGoh0xE0YEsTFeLiB5=zdH8AX+3bg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

21.03.2020 20:59, Andy Lutomirski пишет:
> On Wed, Mar 18, 2020 at 7:16 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>>          Consider the following scenario:  SIGPIPE has SA_ONSTACK
>> handler, SIGSEGV - non-SA_ONSTACK one.  SIGPIPE is delivered
>> and we fail halfway through setting a sigframe for it.
>> OK, we get SIGSEGV forced in, which gets handled not on altstack.
>> But what should happen if we fail *after* having saved the
>> altstack settings into the sigframe that got abandoned?
>>
>>          AFAICS, we get them reset and the original setting
>> entirely lost.  Shouldn't that thing be applied only after
>> we have succeeded in building the frame?  In signal_delivered(),
>> perhaps...
>>
>>          I realize that this is out of scope for POSIX, so it's
>> not a matter of standard compliance, but it looks like a bit
>> of a QoI issue...
> I suspect that the number of real programs that usefully handle
> SIGSEGV due to signal delivery failure is extremely low.  And the
> number of real programs that use SA_ONSTACK and expect to survive when
> the alternate stack is bad may well be zero.
>
> Honestly, if we actually want to make any of this useful, I think a
> better design would be to use an entirely separate signal specifically
> for signal delivery failure.  So we'd have SIGBADSIG, and signal
> delivery failure tries to deliver SIGBADSIG.  The current design is
> like if x86 handled exception failure by sending #PF.  The results
> would be nonsensical.
>
> But adding a feature like this would be silly unless someone actually
> wanted to use it.
> .

IMHO the signal delivery failure should
either call do_exit(), or be quite close to
sigreturn() failure, which is a SIGSEGV
with special si_code IIRC. If you ask me
(as probably the only user of SS_AUTODISARM,
special si_code and all that), I'd say that
I can live well without yet another notification
method. :) And you can always invent new
si_code rather than new signum, in case
the new method is really needed.