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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/