Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong)

  

 
Linux kernel RSS feed   Index | Next | Previous | View Threaded


rostedt at goodmis

Aug 9, 2005, 2:00 PM

Post #1 of 17 (958 views)
Permalink
[PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong)
On Tue, 2005-08-09 at 13:49 -0700, Chris Wright wrote:

>
> SA_NODEFER
> [XSI] If set and sig is caught, sig shall not be added to the thread's
> signal mask on entry to the signal handler unless it is included in
> sa_mask. Otherwise, sig shall always be added to the thread's signal
> mask on entry to the signal handler.
>
> Brodo, is this what you mean?
>
> thanks,
> -chris
> --
>
> Subject: [PATCH] fix SA_NODEFER signals to honor sa_mask
>
> When receiving SA_NODEFER signal, kernel was inapproriately not applying
> the sa_mask. As pointed out by Brodo Stroesser.
>
> Signed-off-by: Chris Wright <chrisw [at] osdl>
> ---
>
> diff --git a/arch/i386/kernel/signal.c b/arch/i386/kernel/signal.c
> --- a/arch/i386/kernel/signal.c
> +++ b/arch/i386/kernel/signal.c
> @@ -577,13 +577,12 @@ handle_signal(unsigned long sig, siginfo
> else
> ret = setup_frame(sig, ka, oldset, regs);
>
> - if (ret && !(ka->sa.sa_flags & SA_NODEFER)) {
> - spin_lock_irq(&current->sighand->siglock);
> - sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
> + spin_lock_irq(&current->sighand->siglock);
> + sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
> + if (ret && !(ka->sa.sa_flags & SA_NODEFER))
> sigaddset(&current->blocked,sig);
> - recalc_sigpending();
> - spin_unlock_irq(&current->sighand->siglock);
> - }
> + recalc_sigpending();
> + spin_unlock_irq(&current->sighand->siglock);
>
> return ret;
> }


Hmm, I think you want this patch. You still need to check the return of
setting up the frames.

-- Steve

Signed-off-by: Steven Rostedt <rostedt [at] goodmis>

--- linux-2.6.13-rc6-git1/arch/i386/kernel/signal.c.orig 2005-08-09 16:54:36.000000000 -0400
+++ linux-2.6.13-rc6-git1/arch/i386/kernel/signal.c 2005-08-09 16:55:24.000000000 -0400
@@ -577,10 +577,11 @@ handle_signal(unsigned long sig, siginfo
else
ret = setup_frame(sig, ka, oldset, regs);

- if (ret && !(ka->sa.sa_flags & SA_NODEFER)) {
+ if (ret) {
spin_lock_irq(&current->sighand->siglock);
sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
- sigaddset(&current->blocked,sig);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(&current->blocked,sig);
recalc_sigpending();
spin_unlock_irq(&current->sighand->siglock);
}


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


chrisw at osdl

Aug 9, 2005, 2:06 PM

Post #2 of 17 (935 views)
Permalink
Re: [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) [In reply to]
* Steven Rostedt (rostedt [at] goodmis) wrote:
> Hmm, I think you want this patch. You still need to check the return of
> setting up the frames.

Indeed, I noticecd just after I sent, and sent an updated patch.
Thanks Steve!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rostedt at goodmis

Aug 9, 2005, 2:07 PM

Post #3 of 17 (933 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
If this is indeed the way things should work. I'll go ahead and fix all
the other architectures.

-- Steve

Signed-off-by: Steven Rostedt <rostedt [at] goodmis>

--- linux-2.6.13-rc6-git1/arch/ppc/kernel/signal.c.orig 2005-08-09 17:00:43.000000000 -0400
+++ linux-2.6.13-rc6-git1/arch/ppc/kernel/signal.c 2005-08-09 17:01:37.000000000 -0400
@@ -759,13 +759,12 @@ int do_signal(sigset_t *oldset, struct p
else
handle_signal(signr, &ka, &info, oldset, regs, newsp);

- if (!(ka.sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka.sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka.sa.sa_mask);
+ if (!(ka.sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked, signr);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);

return 1;
}


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at osdl

Aug 9, 2005, 2:27 PM

Post #4 of 17 (943 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
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."

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 [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rostedt at goodmis

Aug 9, 2005, 8:10 PM

Post #5 of 17 (942 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On Tue, 2005-08-09 at 14:27 -0700, Linus Torvalds wrote:
> 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."
>
> 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).

Actually I take it the other way. The wording is awful. But the "unless
SA_NODEFER or SA_RESETHAND is set, and then including the signal being
delivered". This looks to me that it adds the signal being delivered to
the blocked mask unless the SA_NODEFER or SA_RESETHAND is set. I kind of
wonder if English is the native language of those that wrote this.
>
> 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..

Well, I wrote this (attached) test program to see how signals are
affected by different settings. It's best run under an idle system, so
if someone has another unix out there that can run this and return the
results, we can see how they work. This test program has possible race
conditions but should work fine on an idle system. But that's just the
nature of testing signals and other asynchronous activities, as well as
just writing something up in a couple of minutes ;-)

A non-modified Linux returns this:

sa_mask blocks other signals
SA_NODEFER does not block other signals
SA_NODEFER affects sa_mask
SA_NODEFER and sa_mask does not block sig
!SA_NODEFER blocks sig
SA_NODEFER does not block sig
sa_mask blocks sig

This shows the following:

1. That signals in sa_mask are blocked while the signal handler is
running.
2. SA_NODEFER does not by itself block other signals (this should never
be anything else).
3. SA_NODEFER does affect the sa_mask (which is the topic of this
discussion).
4. When SA_NODEFER is set and sa_mask has the signal itself set, then
the signal is blocked (I believe that this is wrong too. If the signal
is itself in sa_mask then SA_NODEFER should still not let it run. This
should be interresting to see what other unices do).
5. When SA_NODEFER is not set, the signal is blocked (this is correct).
6. When SA_NODEFER is set (with nothing in sa_mask) the signal is not
blocked (also correct).
7. When the signal itself is set in sa_mask, then the signal is blocked
(correct).

With a patched kernel we get the following output:

sa_mask blocks other signals
SA_NODEFER does not block other signals
SA_NODEFER does not affect sa_mask
SA_NODEFER and sa_mask blocks sig
!SA_NODEFER blocks sig
SA_NODEFER does not block sig
sa_mask blocks sig

Here the differences are that SA_NODEFER does _not_ affect the sa_mask,
and that when both the sig is in sa_mask and the SA_NODEFER is set, then
the signal is still blocked. I can see this being useful if the sa_mask
is generated, and the NODEFER is expected to be the default. This allows
for overriding the default.

So, if someone can run this test on another unix system, then we can
have an idea of how others handle this.

-- Steve
Attachments: test_signal.c (3.49 KB)


rostedt at goodmis

Aug 9, 2005, 8:33 PM

Post #6 of 17 (944 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On Tue, 2005-08-09 at 23:10 -0400, Steven Rostedt wrote:
> memset(&act,0,sizeof(act));
> sigaddset(&act.sa_mask,SIGUSR1);
> ret = testsig(&act,SIGUSR1,SIGUSR1);
> if (ret == 1) {
> printf("sa_mask does not block sig\n");
> } else if (ret == 0) {
> printf("sa_mask blocks sig\n");
> } else {
> printf("Unknown return code!!\n");
> }
>
> exit(0);
> exit(0);

Yuck! OK I was into the cut and paste here. This probably would look
much better as

ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("...");
break;
case 1:
printf("...");
break;
default:
printf("Unknown...");
}

And what was I doing with the double exits??

OK, time for bed.

-- Steve
Attachments: test_signal.c (3.61 KB)


bstroesser at fujitsu-siemens

Aug 10, 2005, 2:44 AM

Post #7 of 17 (942 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
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 [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jengelh at linux01

Aug 12, 2005, 11:37 AM

Post #8 of 17 (929 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
>Actually I take it the other way. The wording is awful. But the "unless
>SA_NODEFER or SA_RESETHAND is set, and then including the signal being
>delivered". This looks to me that it adds the signal being delivered to
>the blocked mask unless the SA_NODEFER or SA_RESETHAND is set. I kind of
>wonder if English is the native language of those that wrote this.

So, if in doubt what is really meant - check which of the two/three/+
different behaviors the users out there favor most.



Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


chrisw at osdl

Aug 12, 2005, 11:45 AM

Post #9 of 17 (932 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
* Jan Engelhardt (jengelh [at] linux01) wrote:
> >Actually I take it the other way. The wording is awful. But the "unless
> >SA_NODEFER or SA_RESETHAND is set, and then including the signal being
> >delivered". This looks to me that it adds the signal being delivered to
> >the blocked mask unless the SA_NODEFER or SA_RESETHAND is set. I kind of
> >wonder if English is the native language of those that wrote this.
>
> So, if in doubt what is really meant - check which of the two/three/+
> different behaviors the users out there favor most.

Rather, check what happens in practice on other implementations. I don't
have Solaris, HP-UX, Irix, AIX, etc. boxen at hand, but some folks must.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rostedt at goodmis

Aug 12, 2005, 11:59 AM

Post #10 of 17 (925 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On Fri, 12 Aug 2005, Chris Wright wrote:
> * Jan Engelhardt (jengelh [at] linux01) wrote:
> > So, if in doubt what is really meant - check which of the two/three/+
> > different behaviors the users out there favor most.
>
> Rather, check what happens in practice on other implementations. I don't
> have Solaris, HP-UX, Irix, AIX, etc. boxen at hand, but some folks must.
>

I've supplied this before, but I'll send it again. Attached is a program
that should show the behavior of the sigaction. If someone has one of the
above mentioned boxes, please run this on the box and send back the
results.

-- Steve
Attachments: test_signal.c (3.81 KB)


rostedt at goodmis

Aug 12, 2005, 12:27 PM

Post #11 of 17 (946 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On Fri, 12 Aug 2005, Steven Rostedt wrote:
>
> I've supplied this before, but I'll send it again. Attached is a program
> that should show the behavior of the sigaction. If someone has one of the
> above mentioned boxes, please run this on the box and send back the
> results.

Here it is again. I tried it on another Linux box and realize that the
parent was running before the child was able to initialize the signal
handlers. So I added another sleep. I know sleeps don't guarentee
anything, but this is just a simple test.

Attached is the fixed program.

-- Steve
Attachments: test_signal.c (3.82 KB)


jesper.juhl at gmail

Aug 12, 2005, 12:31 PM

Post #12 of 17 (924 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On 8/12/05, Steven Rostedt <rostedt [at] goodmis> wrote:
> On Fri, 12 Aug 2005, Chris Wright wrote:
> > * Jan Engelhardt (jengelh [at] linux01) wrote:
> > > So, if in doubt what is really meant - check which of the two/three/+
> > > different behaviors the users out there favor most.
> >
> > Rather, check what happens in practice on other implementations. I don't
> > have Solaris, HP-UX, Irix, AIX, etc. boxen at hand, but some folks must.
> >
>
> I've supplied this before, but I'll send it again. Attached is a program
> that should show the behavior of the sigaction. If someone has one of the
> above mentioned boxes, please run this on the box and send back the
> results.
>
I've got a 4-way pSeries p550 running AIX 5.3 here :

$ uname -s -M -p -v -r
AIX 3 5 powerpc IBM,9113-550

Output from your program :

$ ./a.out
Unknown return code!!
Unknown return code!!
Unknown return code!!
Unknown return code!!
Unknown return code!!
Unknown return code!!
sa_mask blocks sig


--
Jesper Juhl <jesper.juhl [at] gmail>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rostedt at goodmis

Aug 12, 2005, 2:08 PM

Post #13 of 17 (944 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On Fri, 2005-08-12 at 21:31 +0200, Jesper Juhl wrote:

> >
> I've got a 4-way pSeries p550 running AIX 5.3 here :
>
> $ uname -s -M -p -v -r
> AIX 3 5 powerpc IBM,9113-550
>
> Output from your program :
>
> $ ./a.out
> Unknown return code!!
> Unknown return code!!
> Unknown return code!!
> Unknown return code!!
> Unknown return code!!
> Unknown return code!!
> sa_mask blocks sig
>

Did you try my updated code (the one with the extra sleep?). Here's
another version where I output the unknown return code. Funny that this
didn't print any other error message. Since the return codes should show
something else.

Please try the attached.

Thanks,

-- Steve
Attachments: test_signal.c (3.68 KB)


rostedt at goodmis

Aug 12, 2005, 2:53 PM

Post #14 of 17 (929 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
Two more systems that are different from Linux.

So far, Linux is the odd ball out.

-- Steve


On Fri, 2005-08-12 at 22:28 +0100, someone else wrote:
>
> SunOS hostname 5.10 Generic sun4u sparc SUNW,Sun-Blade-1000
>
> sa_mask blocks other signals
> SA_NODEFER does not block other signals
> SA_NODEFER does not affect sa_mask
> SA_NODEFER and sa_mask blocks sig
> !SA_NODEFER blocks sig
> SA_NODEFER does not block sig
> sa_mask blocks sig
>
>
> OSF1 hostname V5.1 2650 alpha
>
> sa_mask blocks other signals
> SA_NODEFER does not block other signals
> SA_NODEFER does not affect sa_mask
> SA_NODEFER and sa_mask blocks sig
> !SA_NODEFER blocks sig
> SA_NODEFER does not block sig
> sa_mask blocks sig
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


Ballarin.Marc at gmx

Aug 13, 2005, 11:47 AM

Post #15 of 17 (940 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On Fri, 12 Aug 2005 14:59:49 -0400 (EDT)
Steven Rostedt <rostedt [at] goodmis> wrote:

> On Fri, 12 Aug 2005, Chris Wright wrote:
> > * Jan Engelhardt (jengelh [at] linux01) wrote:
> > > So, if in doubt what is really meant - check which of the two/three/+
> > > different behaviors the users out there favor most.
> >
> > Rather, check what happens in practice on other implementations. I don't
> > have Solaris, HP-UX, Irix, AIX, etc. boxen at hand, but some folks must.
> >
>
> I've supplied this before, but I'll send it again. Attached is a program
> that should show the behavior of the sigaction. If someone has one of the
> above mentioned boxes, please run this on the box and send back the
> results.

This is from NetBSD 2.0:

sa_mask blocks other signals
SA_NODEFER does not block other signals
SA_NODEFER does not affect sa_mask
SA_NODEFER and sa_mask does not block sig
!SA_NODEFER blocks sig
SA_NODEFER does not block sig
sa_mask blocks sig


This is from SFU 3.5 on WinXP (*):

sa_mask blocks other signals
SA_NODEFER does not block other signals
SA_NODEFER does not affect sa_mask
SA_NODEFER and sa_mask blocks sig
!SA_NODEFER blocks sig
SA_NODEFER blocks sig
sa_mask blocks sig

(*) original signal.h did not define SA_NODEFER, so take this with a
grain of salt

Marc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jesper.juhl at gmail

Aug 14, 2005, 4:24 AM

Post #16 of 17 (925 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On 8/12/05, Steven Rostedt <rostedt [at] goodmis> wrote:
> On Fri, 2005-08-12 at 21:31 +0200, Jesper Juhl wrote:
>
> > >
> > I've got a 4-way pSeries p550 running AIX 5.3 here :
> >
> > $ uname -s -M -p -v -r
> > AIX 3 5 powerpc IBM,9113-550
> >
> > Output from your program :
> >
> > $ ./a.out
> > Unknown return code!!
> > Unknown return code!!
> > Unknown return code!!
> > Unknown return code!!
> > Unknown return code!!
> > Unknown return code!!
> > sa_mask blocks sig
> >
>
> Did you try my updated code (the one with the extra sleep?). Here's
> another version where I output the unknown return code. Funny that this
> didn't print any other error message. Since the return codes should show
> something else.
>
> Please try the attached.
>
With the version you attached I get this :

$ uname -s -M -p -v -r
AIX 3 5 powerpc IBM,9113-550
$ gcc test_signal.c
$ ./a.out
sa_mask blocks other signals
SA_NODEFER does not block other signals
SA_NODEFER does not affect sa_mask
SA_NODEFER and sa_mask blocks sig
!SA_NODEFER blocks sig
SA_NODEFER does not block sig
sa_mask blocks sig


--
Jesper Juhl <jesper.juhl [at] gmail>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mrmacman_g4 at mac

Aug 14, 2005, 3:04 PM

Post #17 of 17 (950 views)
Permalink
Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask [In reply to]
On Aug 12, 2005, at 17:53:53, Steven Rostedt wrote:
> Two more systems that are different from Linux.
>
> So far, Linux is the odd ball out.

Make that three more systems (Mac OS X has the same behavior as the
BSDs):

zeus:~ kyle$ uname -a
Darwin zeus.moffetthome.net 8.2.0 Darwin Kernel Version 8.2.0: Fri
Jun 24 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power
Macintosh powerpc
zeus:~ kyle$ ./test_signal
sa_mask blocks other signals
SA_NODEFER does not block other signals
SA_NODEFER does not affect sa_mask
SA_NODEFER and sa_mask blocks sig
!SA_NODEFER blocks sig
SA_NODEFER does not block sig
sa_mask blocks sig

Cheers,
Kyle Moffett

--
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.