Messages in this thread Patch in this message | | | Date | Fri, 4 Jul 2003 17:39:01 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH 2.5.73] Signal stack fixes #1 introduce PF_SS_ACTIVE |
| |
On Fri, 4 Jul 2003, Jörn Engel wrote: > > > Quite frankly, for the recursive SIGSEGV problem, I'd much rather look at > > the signal mask. If SIGSEGV is blocked, we should probably just kill the > > program instead of clearing the blocking and trying to handle the SIGSEGV > > anyway. That should fix your test case, _without_ any subtle side effects. > > What do we do, if a program also uses SA_NOMASK for the SIGSEGV > handler? This is totally stupid, I agree, but it is legal. Should we > declare it illegal from this day on, or is that path blocked as well?
I think we should just continue to do what we do now - sure, we'll loop on SIGSEGV, but hey, it's a user space bug, it's not the kernels problem. It's better to let people continue to do stupid things than try to force changes.
So how about something like the appended? Very simple patch,i and in fact it's more logical than the old behaviour (the old behaviour punched through blocked signals, the new ones says "if you block or ignore the signal we will just kill you through the default action").
Linus
--- --- 1.86/kernel/signal.c Mon Jun 2 13:37:11 2003 +++ edited/kernel/signal.c Fri Jul 4 17:29:43 2003 @@ -797,10 +797,11 @@ int ret; spin_lock_irqsave(&t->sighand->siglock, flags); - if (t->sighand->action[sig-1].sa.sa_handler == SIG_IGN) + if (sigismember(&t->blocked, sig) || t->sighand->action[sig-1].sa.sa_handler == SIG_IGN) { t->sighand->action[sig-1].sa.sa_handler = SIG_DFL; - sigdelset(&t->blocked, sig); - recalc_sigpending_tsk(t); + sigdelset(&t->blocked, sig); + recalc_sigpending_tsk(t); + } ret = specific_send_sig_info(sig, info, t); spin_unlock_irqrestore(&t->sighand->siglock, flags);
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |