Re: 2.6.x signal handler bug

[Davide Libenzi <davidel@xmailserver.org>]

On Mon, 28 Jun 2004, Andries Brouwer wrote:

> On Sat, Jun 26, 2004 at 09:05:34AM -0700, Davide Libenzi wrote:
> 
> > You're receiving a SIGSEGV while SIGSEGV is blocked (force_sig_info). The 
> > force_sig_info call wants to send a signal that the task can't refuse 
> > (kinda The GodFather offers ;). The kernel will noticed this and will 
> > restore the handler to SIG_DFL.
> 
> Yes.
> 
> So checking whether this is POSIX conforming:
> 
> - Blocking a signal in its signal handler is explicitly allowed.
>   (signal(3p))
> - It is unspecified what longjmp() does with the signal mask.
>   (longjmp(3p))
> - The SIGSEGV that occurs during a stack overflow is of the GodFather kind.
>   (getrlimit(3p))
> - If SIGSEGV is generated while blocked, the result is undefined
>   (sigprocmask(3p))
> 
> So, maybe the restoring to SIG_DFL was not required, but it doesnt seem
> incorrect either. It may be a bit surprising.

I think so. Maybe the attached patch?



- Davide




--- a/kernel/signal.c	2004-06-27 15:42:26.000000000 -0700
+++ b/kernel/signal.c	2004-06-27 15:43:28.000000000 -0700
@@ -820,8 +820,9 @@
 	int ret;
 
 	spin_lock_irqsave(&t->sighand->siglock, flags);
-	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;
+	if (sigismember(&t->blocked, sig)) {
+		if (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);
 	}