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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |