Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask

[Bodo Stroesser <bstroesser@fujitsu-siemens.com>]

Linus Torvalds wrote:
> 
> On Tue, 9 Aug 2005, Steven Rostedt wrote:
> 
>>If this is indeed the way things should work. I'll go ahead and fix all
>>the other architectures.
> 
> 
> It does appear that this is what the standards describe in the section 
> quoted by Chris.
> 
> On the other hand, the standard seems to be a bit confused according to 
> google:
> 
>   "This mask is formed by taking the union of the current signal mask and
>    the value of the sa_mask for the signal being delivered unless
>    SA_NODEFER or SA_RESETHAND is set, and then including the signal being
>    delivered. If and when the user's signal handler returns normally, the
>    original signal mask is restored."

I've googled a bit, too. Unfortunately, I don't have much knowledge about
standards and who defines or changes them. Nevertheless it might help
what I've found in "http://www.opengroup.org/austin/docs/austin_251.txt":

   XSH ERN 84 sigaction Accept as marked below

   Change from:
    This mask is formed by taking the union of the current signal mask and
    the value of the sa_mask for the signal being delivered [XSI] [Option
    Start]  unless SA_NODEFER or SA_RESETHAND is set, [Option End] and
    then including the signal being delivered.
   to:
    This mask is formed by taking the union of the current signal mask and
    the value of the sa_mask for the signal being delivered, and [XSI] [Option
    Start]  unless SA_NODEFER or SA_RESETHAND is set, [Option End]
    then including the signal being delivered.

Maybe, the standard already is fixed?

	Bodo

> 
> Quite frankly, the way I read it is actually the old Linux behaviour: the 
> "unless SA_NODEFER or SA_RESETHAND is set" seems to be talking about the 
> whole union of the sa_mask thing, _not_ just the "and the signal being 
> delivered" part. Exactly the way the kernel currently does (except we 
> should apparently _also_ do it for SA_RESETHAND).
> 
> So if we decide to change the kernel behaviour, I'd like this to be in -mm
> for a while before merging (or merge _very_ early after 2.6.13). I could
> imagine this confusing some existing binaries that had only been tested
> with the old Linux behaviour, regardless of what a standard says. 
> Especially since the standard itself is so confusing and badly worded.
> 
> Maybe somebody can tell what other systems do, since I assume the standard 
> is trying to describe behaviour that actually exists in the wild..
> 
> 		Linus