Messages in this thread Patch in this message | | | Date | Sun, 27 Jun 2004 15:45:23 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: 2.6.x signal handler bug |
| |
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); } - 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/
| |