RE: force_sig_info

RE: force_sig_info

[Zach, Yoav]

 

>-----Original Message-----
>From: Linus Torvalds [mailto:torvalds@osdl.org] 
>Sent: Friday, September 03, 2004 21:12
>To: Yoav Zach
>Cc: akpm@osdl.org; linux-kernel@vger.kernel.org; Zach, Yoav
>Subject: Re: force_sig_info
>
>

>
>Why are you blocking signals that you want to get? Sounds like 
>a bug in 
>your program.
>
>		Linus
>

It's a translator - it emulates the behavior of the translated
'process', which is the one that sets the signal mask. On the
other hand, it has its own logic, which requires handling of
certain HW exceptions. In 2.4, signals that were raised due to
HW exceptions could be handled by the translator regardless of
the mask that was set by the translated process. We lost this
ability in 2.6. It will be very good for our product, and I
believe any similar product where a native process emulates 
behavior of another process, if we could have this ability
back.

Thanks,
Yoav.

RE: force_sig_info

[Davide Libenzi]

On Sun, 5 Sep 2004, Zach, Yoav wrote:

> >-----Original Message-----
> >From: Linus Torvalds [mailto:torvalds@osdl.org] 
> >Sent: Friday, September 03, 2004 21:12
> >To: Yoav Zach
> >Cc: akpm@osdl.org; linux-kernel@vger.kernel.org; Zach, Yoav
> >Subject: Re: force_sig_info
> >
> >
> >Why are you blocking signals that you want to get? Sounds like 
> >a bug in 
> >your program.
> 
> It's a translator - it emulates the behavior of the translated
> 'process', which is the one that sets the signal mask. On the
> other hand, it has its own logic, which requires handling of
> certain HW exceptions. In 2.4, signals that were raised due to
> HW exceptions could be handled by the translator regardless of
> the mask that was set by the translated process. We lost this
> ability in 2.6. It will be very good for our product, and I
> believe any similar product where a native process emulates 
> behavior of another process, if we could have this ability
> back.

Below is the latest patch I posted (applies on some Jun 2004 2.6.x) to 
bring 2.6 back to the 2.4 behaviour, but then it has been decided to leave 
2.6 as is.



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

force_sig_info

[Yoav Zach]

The behavior of force_sig_info has changed in kernel 2.6 in
a way that affects very badly our product - in case the user
blocks a signal that must be delivered, the disposition of
the signal is changed to SIG_DFL.
The product that my team is working on is a binary translator
of 32 bit binaries for IPF platforms. We have hard time
juggling between signals that are meant for the translated
process and signals that are meant for the translator, but
till now we managed to let the kernel handle the signal mask.
The new behavior enforces us to handle the signal mask in the
translator, which might have severe implications on performance.
There was a mailing thread about this matter, so apparently,
we're not the only ones who suffer from this change. There
was even a patch that was proposed to make things easier for
existing apps that break because of this change, but somehow,
the thread was cut and I could not see the response to the
proposed patch. Does anyone know the reasons why this patch
did not make it upstream ?

Here is the patch -
=============================================================
--- kernel/signal.c.orig	2004-09-02 00:43:18.751695391 +0800
+++ kernel/signal.c	2004-09-02 00:45:11.815170569 +0800
@@ -822,7 +822,8 @@ force_sig_info(int sig, struct siginfo *
 
 	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);
 	}
=============================================================

Thanks,
Yoav.

Yoav Zach
IA-32 Execution Layer
Performance Tools Lab
Intel Corp.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: force_sig_info

[Linus Torvalds]

On Fri, 3 Sep 2004, Yoav Zach wrote:
>
> The behavior of force_sig_info has changed in kernel 2.6 in
> a way that affects very badly our product - in case the user
> blocks a signal that must be delivered, the disposition of
> the signal is changed to SIG_DFL.

This is very much by design, and it showed real bugs in programs. You 
can't block a signal and expect the kernel to still honor the signal 
handler you had installed. If you blocked it, you're saying "I'm not ready 
to take this signal". And that means that the kernel should refuse to 
deliver it to you.

Why are you blocking signals that you want to get? Sounds like a bug in 
your program.

		Linus