* [RFC][possible bug] when should SS_AUTODISARM have effect?
@ 2020-03-19 2:16 Al Viro
2020-03-21 17:59 ` Andy Lutomirski
0 siblings, 1 reply; 3+ messages in thread
From: Al Viro @ 2020-03-19 2:16 UTC (permalink / raw)
To: Stas Sergeev; +Cc: Ingo Molnar, linux-api, linux-kernel
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...
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC][possible bug] when should SS_AUTODISARM have effect?
2020-03-19 2:16 [RFC][possible bug] when should SS_AUTODISARM have effect? Al Viro
@ 2020-03-21 17:59 ` Andy Lutomirski
2020-03-21 22:24 ` stsp
0 siblings, 1 reply; 3+ messages in thread
From: Andy Lutomirski @ 2020-03-21 17:59 UTC (permalink / raw)
To: Al Viro; +Cc: Stas Sergeev, Ingo Molnar, Linux API, LKML
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC][possible bug] when should SS_AUTODISARM have effect?
2020-03-21 17:59 ` Andy Lutomirski
@ 2020-03-21 22:24 ` stsp
0 siblings, 0 replies; 3+ messages in thread
From: stsp @ 2020-03-21 22:24 UTC (permalink / raw)
To: Andy Lutomirski, Al Viro; +Cc: Ingo Molnar, Linux API, LKML
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-03-21 22:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-19 2:16 [RFC][possible bug] when should SS_AUTODISARM have effect? Al Viro
2020-03-21 17:59 ` Andy Lutomirski
2020-03-21 22:24 ` stsp
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).