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.
