Following up from the other thread (2.6.x signal handler bug) this bring
2.4 behaviour in 2.6.
Signed-off-by: Davide Libenzi <[email protected]>
- Davide
--- a/kernel/signal.c 2004-06-28 14:28:51.000000000 -0700
+++ b/kernel/signal.c 2004-06-28 14:29:31.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) {
+ if (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)) {
sigdelset(&t->blocked, sig);
recalc_sigpending_tsk(t);
}
Davide Libenzi <[email protected]> wrote:
>
>
> Following up from the other thread (2.6.x signal handler bug) this bring
> 2.4 behaviour in 2.6.
>
Pity the poor person who tries to understand this change in a year's time.
Could we have a real changelog please?
On Mon, 28 Jun 2004, Andrew Morton wrote:
>
> Davide Libenzi <[email protected]> wrote:
> >
> >
> > Following up from the other thread (2.6.x signal handler bug) this bring
> > 2.4 behaviour in 2.6.
> >
>
> Pity the poor person who tries to understand this change in a year's time.
> Could we have a real changelog please?
Also, do we really care? The 2.6.x behaviour is nicer in that it tends to
kill programs more abruptly, while 2.4.x will just let a blocked signal
through - possibly letting the program continue, but causing "impossible"
bugs in user space.
I don't think we've had any complaints about the 2.6.x behaviour apart
from the initial discussion a few months ago. I'd much rather have a
debuggable "kill a program that tries to block a synchronous interrupt",
than a potentially totally un-debuggable "let the signal through".
Linus
On Mon, 28 June 2004 14:40:03 -0700, Andrew Morton wrote:
> Davide Libenzi <[email protected]> wrote:
> >
> >
> > Following up from the other thread (2.6.x signal handler bug) this bring
> > 2.4 behaviour in 2.6.
> >
>
> Pity the poor person who tries to understand this change in a year's time.
> Could we have a real changelog please?
It better be a good one. I've hit a real problem that raised more
than a few eyebrows. In short, if some program is stupid enough to
cause a segfault inside a segfault-handler, it doesn't have a reason
to survive.
Your patch will let the poor creature live an unhappy life. No good.
J?rn
--
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf
On Mon, 28 Jun 2004, Linus Torvalds wrote:
> On Mon, 28 Jun 2004, Andrew Morton wrote:
> >
> > Davide Libenzi <[email protected]> wrote:
> > >
> > >
> > > Following up from the other thread (2.6.x signal handler bug) this bring
> > > 2.4 behaviour in 2.6.
> > >
> >
> > Pity the poor person who tries to understand this change in a year's time.
> > Could we have a real changelog please?
>
> Also, do we really care? The 2.6.x behaviour is nicer in that it tends to
> kill programs more abruptly, while 2.4.x will just let a blocked signal
> through - possibly letting the program continue, but causing "impossible"
> bugs in user space.
>
> I don't think we've had any complaints about the 2.6.x behaviour apart
> from the initial discussion a few months ago. I'd much rather have a
> debuggable "kill a program that tries to block a synchronous interrupt",
> than a potentially totally un-debuggable "let the signal through".
It's not that the program try to block the signal. It's the kernel that
during the delivery disables the signal. Then when the signal handler
longjmp(), the signal remains disabled. The next time the signal is raised
again, the kernel does not honor the existing handler, but it reset to
SIG_DFL.
- Davide
On Mon, 28 Jun 2004, Davide Libenzi wrote:
>
> It's not that the program try to block the signal. It's the kernel that
> during the delivery disables the signal. Then when the signal handler
> longjmp(), the signal remains disabled. The next time the signal is raised
> again, the kernel does not honor the existing handler, but it reset to
> SIG_DFL.
So? That program is buggy. Setting the signal handler to SIG_DFL causes it
to be killed with a nice "killed by SIGFPE" message, and now the bug is
visible, and can be fixed.
Hint: it should have done a siglongjmp().
Linus
On Mon, 28 Jun 2004, Linus Torvalds wrote:
> On Mon, 28 Jun 2004, Davide Libenzi wrote:
> >
> > It's not that the program try to block the signal. It's the kernel that
> > during the delivery disables the signal. Then when the signal handler
> > longjmp(), the signal remains disabled. The next time the signal is raised
> > again, the kernel does not honor the existing handler, but it reset to
> > SIG_DFL.
>
> So? That program is buggy. Setting the signal handler to SIG_DFL causes it
> to be killed with a nice "killed by SIGFPE" message, and now the bug is
> visible, and can be fixed.
>
> Hint: it should have done a siglongjmp().
That's what I posted him. Three examples on how to make the thing work
w/out kernel fixes. Then Andries investigated about POSIX compliancy and
noticed that basically it is undefined the behaviour a program will get.
Let's leave as is then.
- Davide
Linus Torvalds wrote:
>
> On Mon, 28 Jun 2004, Davide Libenzi wrote:
> >
> > It's not that the program try to block the signal. It's the kernel that
> > during the delivery disables the signal. Then when the signal handler
> > longjmp(), the signal remains disabled. The next time the signal is raised
> > again, the kernel does not honor the existing handler, but it reset to
> > SIG_DFL.
>
> So? That program is buggy.
Not the signal part. It was written for libc5. There, signals set
with signal(2) were reset when raised (SysV-style). Leaving such a
signal handler with longjmp was perfectly valid.
Glibc2 changed the rules: signals set with signal(2) are not reset
but blocked during delivery (BSD-style). It worked for a while
because the kernel ignored the sigmask for some signals.
So, if one is to blame then glibc2 by breaking compatibility.
With Davide's patch the kernel would be a little bit more tolerant to
old code by keeping the 2.4 behaviour. The current strict behaviour
becomes OK when signal(2) is no longer part of glibc...
Ciao, ET.
On Tue, 29 June 2004 03:24:41 +0200, Edgar Toernig wrote:
> Linus Torvalds wrote:
> >
> > So? That program is buggy.
>
> Not the signal part. It was written for libc5. There, signals set
> with signal(2) were reset when raised (SysV-style). Leaving such a
> signal handler with longjmp was perfectly valid.
But has a very distinct problem. A segmentation fault is usually a
bug and deserves a core dump. Sane default behaviour. If the program
tells the kernel, it can handle segmentation faults on it's own, fine.
But if - while handling the fault - it creates a second one, the claim
was obviously false. Coredump, done.
Now, how can the kernel tell, whether a second segmentation fault
happened inside the handler or after successfully handling the first
one? Right, with longjmp it can't. Coredump, done.
J?rn
--
Victory in war is not repetitious.
-- Sun Tzu