Re: 2.6.x signal handler bug

[Davide Libenzi]

On Sun, 27 Jun 2004, Davide Libenzi wrote:

> 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?

No, the SIG_IGN check should be there ...



- Davide




--- a/kernel/signal.c	2004-06-27 15:48:47.000000000 -0700
+++ b/kernel/signal.c	2004-06-27 15:49:14.000000000 -0700
@@ -821,7 +821,8 @@
 
 	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 (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);
 	}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/