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/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:24 EST