[lkml]   [2020]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 <> 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.

 \ /
  Last update: 2020-03-21 23:30    [W:0.037 / U:10.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site