Re: [RFC][possible bug] when should SS_AUTODISARM have effect?

21.03.2020 20:59, Andy Lutomirski пишет:

On Wed, Mar 18, 2020 at 7:16 PM Al Viro [off-list ref] wrote:

quoted

         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.