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

[stsp]

21.03.2020 20:59, Andy Lutomirski ÐÐÑÐÑ:
> On Wed, Mar 18, 2020 at 7:16 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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.