Messages in this thread | | | Subject | Re: [RFC][possible bug] when should SS_AUTODISARM have effect? | From | stsp <> | Date | Sun, 22 Mar 2020 01:24:05 +0300 |
| |
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.
| |