Re: [patch] signal handler defaulting fix ...

Re: [patch] signal handler defaulting fix ...

[Kai Henningsen]

froese@gmx.de (Edgar Toernig)  wrote on 29.06.04 in <2cfBL-6uJ-9@gated-at.bofh.it>:

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

You might want to study /usr/include/signal.h and /usr/include/feature.h.

And then you might try stuff like -D_SVID_SOURCE or -Dsignal=sysv_signal,  
for example.

And stop blaming glibc for your failures.

MfG Kai

[patch] signal handler defaulting fix ...

[Davide Libenzi]

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 <davidel@xmailserver.org>



- 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);
 	}

Re: [patch] signal handler defaulting fix ...

[Andrew Morton]

Davide Libenzi <davidel@xmailserver.org> 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?

Re: [patch] signal handler defaulting fix ...

[Linus Torvalds]

On Mon, 28 Jun 2004, Andrew Morton wrote:
>
> Davide Libenzi <davidel@xmailserver.org> 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

Re: [patch] signal handler defaulting fix ...

[Davide Libenzi]

On Mon, 28 Jun 2004, Linus Torvalds wrote:

> On Mon, 28 Jun 2004, Andrew Morton wrote:
> >
> > Davide Libenzi <davidel@xmailserver.org> 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

Re: [patch] signal handler defaulting fix ...

[Linus Torvalds]

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

Re: [patch] signal handler defaulting fix ...

[Davide Libenzi]

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

Re: [patch] signal handler defaulting fix ...

[Edgar Toernig]

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.

Re: [patch] signal handler defaulting fix ...

[Jörn Engel]

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

Re: [patch] signal handler defaulting fix ...

[Jörn Engel]

On Mon, 28 June 2004 14:40:03 -0700, Andrew Morton wrote:
> Davide Libenzi <davidel@xmailserver.org> 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