Re: Never mind. Re: Signal left blocked after signal handler.

Re: Never mind. Re: Signal left blocked after signal handler.

[Albert Cahalan]

> One difference in 2.4.x and 2.6.x is the signal blocking
> wrt blocked signals that are _forced_ (ie anything that
> is thread-synchronous, like a SIGSEGV/SIGTRAP/SIGBUS that
> happens as a result of a fault):
>
>  - in 2.4.x they will just punch through the block
>  - in 2.6.x they will refuse to punch through a blocked
>    signal, but since they can't be delivered they will
>    cause the process to be killed.
...
> and in 2.4.x this will cause infinte SIGSEGV's (well,
> they'll be caught by the stack size eventually, but you
> see the problem: do a "strace" to see what's going on).
> In 2.6.x the second SIGSEGV will just kill the program
> immediately.

How about making the process sleep in a killable state?

This is as if the blocking was obeyed, but doesn't
burn CPU time. Only a debugger should be able to
tell the difference.

Re: Never mind. Re: Signal left blocked after signal handler.

[Ingo Oeser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 26 November 2003 22:53, Albert Cahalan wrote:
[2.4 vs. 2.6 wrt. thread synchronous signals]
> How about making the process sleep in a killable state?
>
> This is as if the blocking was obeyed, but doesn't
> burn CPU time. Only a debugger should be able to
> tell the difference.

This has 2 problems:

1) Servers and PID files or servers and simple monitoring software.
2) Processes spawned from init, which will not respawn.

Regards


Ingo Oeser

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/xb/mU56oYWuOrkARAmNaAKCL1uojbOpMtMdSvAl6B9rBW51CTgCgypP8
NlbaIac25oefxcHL9WlzxyE=
=h6UI
-----END PGP SIGNATURE-----

Re: Never mind. Re: Signal left blocked after signal handler.

[Albert Cahalan]

On Thu, 2003-11-27 at 04:11, Ingo Oeser wrote:
> On Wednesday 26 November 2003 22:53, Albert Cahalan wrote:

> [2.4 vs. 2.6 wrt. thread synchronous signals]
> > How about making the process sleep in a killable state?
> >
> > This is as if the blocking was obeyed, but doesn't
> > burn CPU time. Only a debugger should be able to
> > tell the difference.
> 
> This has 2 problems:
> 
> 1) Servers and PID files or servers and simple monitoring software.
> 2) Processes spawned from init, which will not respawn.

It has benefits:

1. Continuous respawning is no good.
2. If the processes sleeps, you can attach a debugger.

The obviously correct behavior is to go back into
user space, likely to take the signal again. The only
thing wrong with this is that it eats CPU time.
So _pretend_ to do that. Have the process sleep,
ideally with an "R" state as seen in /proc, and maybe
even go back to the crazy loop if someone attaches a
debugger.

The crazy loop is most correct though. It's what the
user asked for. It perfectly handles the case of a
repeating SIGFPE (blocked) followed by some other
thread unmapping a page of instructions or data that
turns the SIGFPE into a SIGSEGV.

Re: Never mind. Re: Signal left blocked after signal handler.

[Jörn Engel]

On Thu, 27 November 2003 10:45:39 -0500, Albert Cahalan wrote:
> 
> It has benefits:
> 
> 1. Continuous respawning is no good.

But trivial to notice. :)

> 2. If the processes sleeps, you can attach a debugger.

If aunt Tilly has a core dump, her son can extract it and send it to
some developer.  No need for you to drive over to aunt Tilly.

> The obviously correct behavior is to go back into
> user space, likely to take the signal again. The only
> thing wrong with this is that it eats CPU time.
> So _pretend_ to do that. Have the process sleep,
> ideally with an "R" state as seen in /proc, and maybe
> even go back to the crazy loop if someone attaches a
> debugger.
> 
> The crazy loop is most correct though. It's what the
> user asked for. It perfectly handles the case of a
> repeating SIGFPE (blocked) followed by some other
> thread unmapping a page of instructions or data that
> turns the SIGFPE into a SIGSEGV.

"It just what you asked for, but not what you wanted."

I am a firm non-believer in the trust-the-programmer paradigm.  How
many people actually intend to do NULL-pointer dereferences, etc?  To
make this possible "if you really really want to" is ok, but at least
make the bad behaviour hard to trigger by accident.

What Linux did in 2.5.7x is not exacly what I would have done, but it
makes it hard to do the Wrong Thing (tm) by accident, while allowing
it for those who really want it.  Good enough for most users.

Jörn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu

Re: Never mind. Re: Signal left blocked after signal handler.

[Jamie Lokier]

Linus Torvalds wrote:
> I personally think it is "good taste" to actually set the SA_NODEFER flag
> if you know you depend on the behaviour, but if there are lots of existing
> applications that actually depend on the "forced punch-through" behaviour,
> then I'll obviously have to change the 2.6.x behaviour (a stable
> user-level ABI is a lot more important than my personal preferences).

I also have a program which depends on the behaviour of nesting
SIGSEGVs, however luckily I already set the SA_NODEFER flag :)

-- Jamie

Re: Never mind. Re: Signal left blocked after signal handler.

[Linus Torvalds]

On Wed, 26 Nov 2003, Bruce Perens wrote:
>
> The behavior of 2.4 seems to be the same used by some dozens of Unix
> systems upon which my confidence test passed.

Interesting. I know the 2.4.x behaviour wasn't arrived at due to any
"compatibility testing" - it was purely a matter of "minimal code". The
fact that other unixes did the same despite no other commonalities is
interesting in itself ;)

But we actually had another unrelated thread about this last week, where
SIGTRAP on x86 worked differently under Linux and FreeBSD (both 2.4.x and
2.6.x behaviour differed from BSD behaviour), so clearly it's _not_ a 100%
correlation.

> I agree that we should not be wrong in the same way as everyone else,
> and wonder if POSIX says anything about this. I could have been the only
> one using this "feature".

I can't say that I'd ever seen this documented anywhere.

I personally think it is "good taste" to actually set the SA_NODEFER flag
if you know you depend on the behaviour, but if there are lots of existing
applications that actually depend on the "forced punch-through" behaviour,
then I'll obviously have to change the 2.6.x behaviour (a stable
user-level ABI is a lot more important than my personal preferences).

But if ElectricFence is the only thing that cares, I'd rather just EF
added a SA_NODEFER..

		Linus

Re: Never mind. Re: Signal left blocked after signal handler.

[Bruce Perens]

What happened is that I attempted to simplify the test code to send to 
you, and simplified out the problem by using
kill() instead of causing a fault. :-)

It's just what you describe here:

>One difference in 2.4.x and 2.6.x is the signal blocking wrt blocked
>signals that are _forced_ (ie anything that is thread-synchronous, like a
>SIGSEGV/SIGTRAP/SIGBUS that happens as a result of a fault):
>
> - in 2.4.x they will just punch through the block
> - in 2.6.x they will refuse to punch through a blocked signal, but
>   since they can't be delivered they will cause the process to be
>   killed
>  
>
The behavior of 2.4 seems to be the same used by some dozens of Unix 
systems upon which my confidence test passed.

I agree that we should not be wrong in the same way as everyone else, 
and wonder if POSIX says anything about this. I could have been the only 
one using this "feature".

    Thanks

    Bruce

Re: Never mind. Re: Signal left blocked after signal handler.

[Linus Torvalds]

On Wed, 26 Nov 2003, Bruce Perens wrote:
>
> The test code works on 2.4, but the electric fence confidence test does
> not. Maybe something odd with SIGSEGV, which is
> what that confidence test is catching. I will go back and see why.

One difference in 2.4.x and 2.6.x is the signal blocking wrt blocked
signals that are _forced_ (ie anything that is thread-synchronous, like a
SIGSEGV/SIGTRAP/SIGBUS that happens as a result of a fault):

 - in 2.4.x they will just punch through the block
 - in 2.6.x they will refuse to punch through a blocked signal, but
   since they can't be delivered they will cause the process to be
   killed.

Trivial test program:

	#include <signal.h>
	#include <stdlib.h>

	void sigsegv(int sig)
	{
		*(int *)0=0;
	}

	int main(int argc, char **argv)
	{
		struct sigaction sa = { .sa_handler = sigsegv };

		sigaction(SIGSEGV, &sa, NULL);
		*(int *)0 = 0;
	}

and in 2.4.x this will cause infinte SIGSEGV's (well, they'll be caught by
the stack size eventually, but you see the problem: do a "strace" to see
what's going on). In 2.6.x the second SIGSEGV will just kill the program
immediately.

If you _want_ the recursive behaviour, you should add

	.sa_flags = SA_NODEFER

to the sigaction initializer.

I don't understand why your test-program works differently on 2.4.x,
though, since a "kill()" system call is _not_ thread-synchronous, and
should never punch through anything. Not even on 2.4.x.

		Linus