Re: sigaltstack fun

[David Miller <davem@davemloft.net>]

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Mon, 26 Nov 2012 05:15:44 +0000

> On Mon, Nov 26, 2012 at 05:10:02AM +0000, Al Viro wrote:
>> On Sun, Nov 18, 2012 at 10:27:24PM -0500, David Miller wrote:
>> > > Cc: stable@vger.kernel.org
>> > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>> > 
>> > Applied, thanks.
>> 
>> Hmm...  There's something odd going on with {rt_,}sigaction on sparc -
>> we *do* have sa_restorer in struct sigaction and struct old_sigaction,
>> but it's not used for anything whatsoever.  There's also a separately
>> passed restorer pointer for rt_sigaction() and *that* is used instead,
>> but not reported via *oact.
>> 
>> What's the reason for that weirdness?  I understand why we do that on
>> alpha (we have no sa_restorer in struct sigaction we'd inherited from
>> OSF/1), but sparc always had perfectly normal sigaction->sa_restorer
>> field all along - even for old sigaction(2)...
> 
> PS: speaking of weirdness, what's the reason for sparc and ppc (and nothing
> else) expecting the first argument of sigaction(2) to be minus signal
> number?  ABI archaeology is fun...

It's because of stupidity.

We had two sigaction interpretations, and distinguished the two cases
by whether the signal passed in was positive or negative.

The positive code got phased out and simply deleted, leaving only
the negative case.

If you look into ancient trees (f.e. 2.4.x) you'll see stuff like
this:

	if (sig < 0) {
		current->thread.new_signal = 1;
		sig = -sig;
	}

in sparc_sigaction().

The main problem is that, originally, I didn't pass a siginfo into the
signal handler.  I didn't want to break applications that made use of
the arguments I did provide.  So this was the compatability facility.

If you passed in a negative signal number, I passed the signal()
handler args as they are documented in sigaction(2).  Otherwise
I passed in whatever I had passed previously.