* Signal handling possibly wrong
@ 2005-08-09 17:44 Bodo Stroesser
2005-08-09 18:26 ` Robert Wilkens
2005-08-09 18:50 ` smbus driver for ati xpress 200m yhlu
0 siblings, 2 replies; 36+ messages in thread
From: Bodo Stroesser @ 2005-08-09 17:44 UTC (permalink / raw)
To: linux-kernel
Hi,
reading man pages for sigaction and comparing it to what kernel does
when starting a signal handler (i386, s390, ppc and others), I think
one of both might be wrong.
From man pages:
sa_mask gives a mask of signals which should be blocked during
execution of the signal handler. In addition, the signal which
triggered the handler will be blocked, unless the SA_NODEFER or
SA_NOMASK flags are used.
From arch/i386/kernel/signal.c:
if (ret && !(ka->sa.sa_flags & SA_NODEFER)) {
spin_lock_irq(¤t->sighand->siglock);
sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
sigaddset(¤t->blocked,sig);
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
}
If I understand man pages correctly, the handled signal should be blocked
depending on SA_NODEFER, while sa_mask should be used unconditionally to
block additional signals.
Kernel code blocks both "handled signal" _and_ sa_mask only if SA_NODEFER
isn't set.
Which is the right behavior?
Regards
Bodo
P.S.:
Please CC me, I'm not on the list.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 17:44 Signal handling possibly wrong Bodo Stroesser
@ 2005-08-09 18:26 ` Robert Wilkens
2005-08-09 18:32 ` Bodo Stroesser
2005-08-09 18:50 ` smbus driver for ati xpress 200m yhlu
1 sibling, 1 reply; 36+ messages in thread
From: Robert Wilkens @ 2005-08-09 18:26 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: linux-kernel
> Kernel code blocks both "handled signal" _and_ sa_mask only if SA_NODEFER
> isn't set.
>
> Which is the right behavior?
Perhaps both?
I'm novice here, but if i'm reading the man page correctly, it says:
SA_NODEFER
Do not prevent the signal from being received from within
its own signal handler.
(they also imply that SA_NOMASK is the old name for this,
which might make it clear what it's use is).
In which case blocking (masking) when it's not set is exactly what it's
supposed to do.
-Rob
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 18:26 ` Robert Wilkens
@ 2005-08-09 18:32 ` Bodo Stroesser
2005-08-09 18:39 ` Robert Wilkens
0 siblings, 1 reply; 36+ messages in thread
From: Bodo Stroesser @ 2005-08-09 18:32 UTC (permalink / raw)
To: Robert Wilkens; +Cc: linux-kernel
Robert Wilkens wrote:
>>Kernel code blocks both "handled signal" _and_ sa_mask only if SA_NODEFER
>>isn't set.
>>
>>Which is the right behavior?
>
>
> Perhaps both?
>
> I'm novice here, but if i'm reading the man page correctly, it says:
>
> SA_NODEFER
> Do not prevent the signal from being received from within
> its own signal handler.
> (they also imply that SA_NOMASK is the old name for this,
> which might make it clear what it's use is).
>
> In which case blocking (masking) when it's not set is exactly what it's
> supposed to do.
>
> -Rob
Yes. That's true.
But what about sa_mask? Description of SA_NODEFER and sa_mask both do not
say, that usage of sa_mask depends on SA_NODEFER.
But kernel only uses sa_mask, if SA_NODEFER isn't set.
So, I think man page and kernel are not consistent.
Bodo
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 18:32 ` Bodo Stroesser
@ 2005-08-09 18:39 ` Robert Wilkens
2005-08-09 18:44 ` Bodo Stroesser
0 siblings, 1 reply; 36+ messages in thread
From: Robert Wilkens @ 2005-08-09 18:39 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: linux-kernel
Bodo,
SA_MASK is a flag... Which you use to tell it what to do with the data
you've given it and/or it gets. You gave it sa_mask (lower-case).
SA_NOMASK means don't use the mask -- the pseudonym (new-word) for
SA_NOMASK is SA_NODEFER (renamed, perhaps, because it may defer some or
all signals rather than throwing them away, you probably can receive the
waiting signals by clearing the SA_NODEFER flag on a subsequent call).
If you want to take this off-list, I'm OK with that..
Please describe what you would expect SA_NODEFER to do in your own
language if you don't understand what I seem to understand.
-Rob
On Tue, 2005-08-09 at 20:32 +0200, Bodo Stroesser wrote:
> Robert Wilkens wrote:
> >>Kernel code blocks both "handled signal" _and_ sa_mask only if SA_NODEFER
> >>isn't set.
> >>
> >>Which is the right behavior?
> >
> >
> > Perhaps both?
> >
> > I'm novice here, but if i'm reading the man page correctly, it says:
> >
> > SA_NODEFER
> > Do not prevent the signal from being received from within
> > its own signal handler.
> > (they also imply that SA_NOMASK is the old name for this,
> > which might make it clear what it's use is).
> >
> > In which case blocking (masking) when it's not set is exactly what it's
> > supposed to do.
> >
> > -Rob
>
> Yes. That's true.
>
> But what about sa_mask? Description of SA_NODEFER and sa_mask both do not
> say, that usage of sa_mask depends on SA_NODEFER.
> But kernel only uses sa_mask, if SA_NODEFER isn't set.
>
> So, I think man page and kernel are not consistent.
>
> Bodo
> -
> 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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 18:39 ` Robert Wilkens
@ 2005-08-09 18:44 ` Bodo Stroesser
2005-08-09 19:04 ` Robert Wilkens
0 siblings, 1 reply; 36+ messages in thread
From: Bodo Stroesser @ 2005-08-09 18:44 UTC (permalink / raw)
To: Robert Wilkens; +Cc: linux-kernel
Robert Wilkens wrote:
> Bodo,
>
> SA_MASK is a flag... Which you use to tell it what to do with the data
> you've given it and/or it gets. You gave it sa_mask (lower-case).
> SA_NOMASK means don't use the mask -- the pseudonym (new-word) for
> SA_NOMASK is SA_NODEFER (renamed, perhaps, because it may defer some or
> all signals rather than throwing them away, you probably can receive the
> waiting signals by clearing the SA_NODEFER flag on a subsequent call).
>
> If you want to take this off-list, I'm OK with that..
>
> Please describe what you would expect SA_NODEFER to do in your own
> language if you don't understand what I seem to understand.
>
> -Rob
> On Tue, 2005-08-09 at 20:32 +0200, Bodo Stroesser wrote:
>
Sorry, unfortunately you are not right. See this (from man page for sigaction):
struct sigaction {
void (*sa_handler)(int);
void (*sa_sigaction)(int, siginfo_t *, void *);
sigset_t sa_mask;
int sa_flags;
void (*sa_restorer)(void);
}
Please read the text about element sa_mask of struct sigaction to
understand what I'm talking about.
Regards
Bodo
>>Robert Wilkens wrote:
>>
>>>>Kernel code blocks both "handled signal" _and_ sa_mask only if SA_NODEFER
>>>>isn't set.
>>>>
>>>>Which is the right behavior?
>>>
>>>
>>>Perhaps both?
>>>
>>>I'm novice here, but if i'm reading the man page correctly, it says:
>>>
>>>SA_NODEFER
>>> Do not prevent the signal from being received from within
>>> its own signal handler.
>>> (they also imply that SA_NOMASK is the old name for this,
>>> which might make it clear what it's use is).
>>>
>>>In which case blocking (masking) when it's not set is exactly what it's
>>>supposed to do.
>>>
>>>-Rob
>>
>>Yes. That's true.
>>
>>But what about sa_mask? Description of SA_NODEFER and sa_mask both do not
>>say, that usage of sa_mask depends on SA_NODEFER.
>>But kernel only uses sa_mask, if SA_NODEFER isn't set.
>>
>>So, I think man page and kernel are not consistent.
>>
>> Bodo
>>-
>>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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* smbus driver for ati xpress 200m
2005-08-09 17:44 Signal handling possibly wrong Bodo Stroesser
2005-08-09 18:26 ` Robert Wilkens
@ 2005-08-09 18:50 ` yhlu
2005-08-09 22:57 ` Andi Kleen
1 sibling, 1 reply; 36+ messages in thread
From: yhlu @ 2005-08-09 18:50 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
anyone is working on add driver for ati xpress 200m?
without that My turion notebook, can not work read the battery status.
I guess sbs-cm need that driver in kernel.
YH
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 18:44 ` Bodo Stroesser
@ 2005-08-09 19:04 ` Robert Wilkens
2005-08-09 19:33 ` Steven Rostedt
2005-08-09 19:33 ` Jeremy Maitin-Shepard
0 siblings, 2 replies; 36+ messages in thread
From: Robert Wilkens @ 2005-08-09 19:04 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: linux-kernel
[resent - previous message not properly addressed]
It says "signal is blocked, UNLESS SA_NODEFER is used.."
Which means if NODEFER is used, it's not masked (SA_NOMASK)..
I don't understand how i'm wrong (maybe I have mental problems that are
worse than I thought). If you want to explain off-list or on-list
(depending on whether others are getting annoyed at me) you can. Or
just ignore me and i'll go away and someone else who wants to look at it
can.
-Rob
On Tue, 2005-08-09 at 20:44 +0200, Bodo Stroesser wrote:
> Robert Wilkens wrote:
> > Bodo,
> >
> > SA_MASK is a flag... Which you use to tell it what to do with the data
> > you've given it and/or it gets. You gave it sa_mask (lower-case).
> > SA_NOMASK means don't use the mask -- the pseudonym (new-word) for
> > SA_NOMASK is SA_NODEFER (renamed, perhaps, because it may defer some or
> > all signals rather than throwing them away, you probably can receive the
> > waiting signals by clearing the SA_NODEFER flag on a subsequent call).
> >
> > If you want to take this off-list, I'm OK with that..
> >
> > Please describe what you would expect SA_NODEFER to do in your own
> > language if you don't understand what I seem to understand.
> >
> > -Rob
> > On Tue, 2005-08-09 at 20:32 +0200, Bodo Stroesser wrote:
> >
>
> Sorry, unfortunately you are not right. See this (from man page for sigaction):
>
> struct sigaction {
> void (*sa_handler)(int);
> void (*sa_sigaction)(int, siginfo_t *, void *);
> sigset_t sa_mask;
> int sa_flags;
> void (*sa_restorer)(void);
> }
>
> Please read the text about element sa_mask of struct sigaction to
> understand what I'm talking about.
>
> Regards
> Bodo
>
>
> >>Robert Wilkens wrote:
> >>
> >>>>Kernel code blocks both "handled signal" _and_ sa_mask only if SA_NODEFER
> >>>>isn't set.
> >>>>
> >>>>Which is the right behavior?
> >>>
> >>>
> >>>Perhaps both?
> >>>
> >>>I'm novice here, but if i'm reading the man page correctly, it says:
> >>>
> >>>SA_NODEFER
> >>> Do not prevent the signal from being received from within
> >>> its own signal handler.
> >>> (they also imply that SA_NOMASK is the old name for this,
> >>> which might make it clear what it's use is).
> >>>
> >>>In which case blocking (masking) when it's not set is exactly what it's
> >>>supposed to do.
> >>>
> >>>-Rob
> >>
> >>Yes. That's true.
> >>
> >>But what about sa_mask? Description of SA_NODEFER and sa_mask both do not
> >>say, that usage of sa_mask depends on SA_NODEFER.
> >>But kernel only uses sa_mask, if SA_NODEFER isn't set.
> >>
> >>So, I think man page and kernel are not consistent.
> >>
> >> Bodo
> >>-
> >>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/
> -
> 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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 19:04 ` Robert Wilkens
@ 2005-08-09 19:33 ` Steven Rostedt
2005-08-09 19:41 ` Bodo Stroesser
2005-08-09 19:33 ` Jeremy Maitin-Shepard
1 sibling, 1 reply; 36+ messages in thread
From: Steven Rostedt @ 2005-08-09 19:33 UTC (permalink / raw)
To: Robert Wilkens; +Cc: linux-kernel, Bodo Stroesser
On Tue, 2005-08-09 at 15:04 -0400, Robert Wilkens wrote:
> [resent - previous message not properly addressed]
>
> It says "signal is blocked, UNLESS SA_NODEFER is used.."
>
> Which means if NODEFER is used, it's not masked (SA_NOMASK)..
>
I believe I understand what Bodo is saying. The man pages seem to imply
that the NODEFER only affects the signal being sent. Where as, in the
kernel, the NODEFER flag affects all signals in the sa_mask.
Let's look at the man pages again:
sa_mask gives a mask of signals which should be blocked during execu-
tion of the signal handler. In addition, the signal which triggered
the handler will be blocked, unless the SA_NODEFER flag is used.
The "In addition" is what makes this look like the kernel is wrong. So
the man pages says that the sa_mask is the mask of signals that should
be blocked during exection of the signal handle (regardless) of the
SA_NODEFER. It doesn't imply that the sa_mask would only work if the
SA_NODEFER was not set. The SA_NODEFER seems to imply here that, if
set, the signal that is running could be called again.
It also seems to imply the other way around. That is, that the signal
that is running would be blocked regardless of the sa_mask, and only
would not be blocked if the SA_NODEFER is set.
To me, the man pages make more sense, and I think the kernel is wrong.
> I don't understand how i'm wrong (maybe I have mental problems that are
> worse than I thought). If you want to explain off-list or on-list
> (depending on whether others are getting annoyed at me) you can. Or
> just ignore me and i'll go away and someone else who wants to look at it
> can.
Don't take this off list, since I'm sure there are others here that can
add valid input.
-- Steve
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 19:04 ` Robert Wilkens
2005-08-09 19:33 ` Steven Rostedt
@ 2005-08-09 19:33 ` Jeremy Maitin-Shepard
1 sibling, 0 replies; 36+ messages in thread
From: Jeremy Maitin-Shepard @ 2005-08-09 19:33 UTC (permalink / raw)
To: linux-kernel
It appears to me that Bodo Stroesser is correct. The description of
sa_mask given in the man page is:
"sa_mask gives a mask of signals which should be blocked during
execution of the signal handler. In addition, the signal which
triggered the handler will be blocked, unless the SA_NODEFER flag is
used."
Note that the "unless the SA_NODEFER flag is used" clause applies only
to "In addition, the signal which triggered the handler will be
blocked." The first sentence of the description, which is unaffected by
this clause, states that the signals specified in sa_mask will be
blocked while the signal handler being installed executes. The
description of sa_mask in no way suggests that if SA_NODEFER is
specified, the signals specified in sa_mask will not be blocked.
The description of SA_NODEFER given in the man page is:
"SA_NODEFER
Do not prevent the signal from being received from within its own signal
handler. SA_NOMASK is an obsolete, non-standard synonym for this flag."
Clearly, the first sentence of this description is the only one which
specifies any behavior at all, so the second sentence can be ignored.
This description only states that SA_NODEFER will block the signal for
which a signal handler is being installed while the signal handler being
installed executes. It does not indicate that SA_NODEFER has any effect
on the blocking of signals other than the one for which a handler is
being installed, and thus it should be assumed that it has no such
effect.
The source code indicates, though, that SA_NODEFER has precisely this
effect; specifying SA_NODEFER prevents the signals specified in sa_mask
from being blocked (an exception to the normal behavior of sa_mask,
described by the first sentence of the sa_mask man page description
included above), when neither the description of sa_mask nor the
description of SA_NODEFER specifies such an exception.
--
Jeremy Maitin-Shepard
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 19:33 ` Steven Rostedt
@ 2005-08-09 19:41 ` Bodo Stroesser
2005-08-09 20:03 ` Steven Rostedt
0 siblings, 1 reply; 36+ messages in thread
From: Bodo Stroesser @ 2005-08-09 19:41 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Robert Wilkens, linux-kernel
Steven Rostedt wrote:
> On Tue, 2005-08-09 at 15:04 -0400, Robert Wilkens wrote:
>
>>[resent - previous message not properly addressed]
>>
>>It says "signal is blocked, UNLESS SA_NODEFER is used.."
>>
>>Which means if NODEFER is used, it's not masked (SA_NOMASK)..
>>
>
>
> I believe I understand what Bodo is saying. The man pages seem to imply
> that the NODEFER only affects the signal being sent. Where as, in the
> kernel, the NODEFER flag affects all signals in the sa_mask.
>
> Let's look at the man pages again:
>
> sa_mask gives a mask of signals which should be blocked during execu-
> tion of the signal handler. In addition, the signal which triggered
> the handler will be blocked, unless the SA_NODEFER flag is used.
>
> The "In addition" is what makes this look like the kernel is wrong. So
> the man pages says that the sa_mask is the mask of signals that should
> be blocked during exection of the signal handle (regardless) of the
> SA_NODEFER. It doesn't imply that the sa_mask would only work if the
> SA_NODEFER was not set. The SA_NODEFER seems to imply here that, if
> set, the signal that is running could be called again.
>
> It also seems to imply the other way around. That is, that the signal
> that is running would be blocked regardless of the sa_mask, and only
> would not be blocked if the SA_NODEFER is set.
>
> To me, the man pages make more sense, and I think the kernel is wrong.
Yes, that's what I think, too. If someone doesn't want additional signals
to be masked, he can set sa_mask to be empty.
OTOH, I have no idea, what POSIX specifies. Maybe kernel is right and man
page is wrong?
Bodo
>
>
>>I don't understand how i'm wrong (maybe I have mental problems that are
>>worse than I thought). If you want to explain off-list or on-list
>>(depending on whether others are getting annoyed at me) you can. Or
>>just ignore me and i'll go away and someone else who wants to look at it
>>can.
>
>
> Don't take this off list, since I'm sure there are others here that can
> add valid input.
>
> -- Steve
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 19:41 ` Bodo Stroesser
@ 2005-08-09 20:03 ` Steven Rostedt
2005-08-09 20:19 ` Steven Rostedt
0 siblings, 1 reply; 36+ messages in thread
From: Steven Rostedt @ 2005-08-09 20:03 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: Robert Wilkens, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 699 bytes --]
On Tue, 2005-08-09 at 21:41 +0200, Bodo Stroesser wrote:
> S
> > To me, the man pages make more sense, and I think the kernel is wrong.
>
> Yes, that's what I think, too. If someone doesn't want additional signals
> to be masked, he can set sa_mask to be empty.
> OTOH, I have no idea, what POSIX specifies. Maybe kernel is right and man
> page is wrong?
>
> Bodo
> >
Man pages and kernel are right. I just tested this out on 2.6.13-rc3
with the attached program and it seems to follow what is stated in the
man pages. So the assumption of what the code did by looking at it
proves to be the mistake. :-)
Conclusion: sa_mask defers the signals. SA_NODEFER defers the sent
signal.
-- Steve
[-- Attachment #2: signal.c --]
[-- Type: text/x-csrc, Size: 2423 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <sys/types.h>
#include <unistd.h>
void user1(int x)
{
int pid = getpid();
printf("pid[%d]: user1 start\n",pid);
sleep(5);
printf("pid[%d]: user1 stopped\n",pid);
}
void user2(int x)
{
int pid = getpid();
printf("pid[%d]:in user2\n",pid);
}
void intr(int x)
{
int pid = getpid();
printf("pid[%d]: received SIGINT\n",pid);
exit(0);
}
void start1(void)
{
struct sigaction act;
memset(&act,0,sizeof(act));
act.sa_handler = intr;
if ((sigaction(SIGINT,&act,NULL)) < 0) {
perror("child1: sigaction");
exit(-1);
}
act.sa_handler = user1;
sigaddset(&act.sa_mask,SIGUSR2);
if ((sigaction(SIGUSR1,&act,NULL)) < 0) {
perror("child1: sigaction");
exit(-1);
}
act.sa_handler = user2;
if ((sigaction(SIGUSR2,&act,NULL)) < 0) {
perror("child1: sigaction");
exit(-1);
}
for (;;)
;
}
void start2(void)
{
struct sigaction act;
memset(&act,0,sizeof(act));
act.sa_handler = intr;
if ((sigaction(SIGINT,&act,NULL)) < 0) {
perror("child2: sigaction");
exit(-1);
}
act.sa_handler = user1;
act.sa_flags |= SA_NODEFER;
if ((sigaction(SIGUSR1,&act,NULL)) < 0) {
perror("child2: sigaction");
exit(-1);
}
act.sa_handler = user2;
if ((sigaction(SIGUSR2,&act,NULL)) < 0) {
perror("child1: sigaction");
exit(-1);
}
for (;;)
;
}
int main(int argc, char **argv)
{
int pid[2];
if ((pid[0] = fork()) < 0) {
perror("fork");
} else if (!pid[0]) {
start1();
exit(0);
}
if ((pid[1] = fork()) < 0) {
perror("fork");
} else if (!pid[1]) {
start2();
exit(0);
}
printf("parent sending %d SIGUSR1\n",pid[0]);
kill(pid[0],SIGUSR1);
sleep(1);
printf("parent sending %d SIGUSR2\n",pid[0]);
kill(pid[0],SIGUSR2);
sleep(5);
printf("parent sending %d SIGUSR1\n",pid[0]);
kill(pid[0],SIGUSR1);
sleep(1);
printf("parent sending %d SIGUSR1\n",pid[0]);
kill(pid[0],SIGUSR1);
sleep(1);
printf("parent sending %d SIGINT\n",pid[0]);
kill(pid[0],SIGINT);
printf("parent sending %d SIGUSR1\n",pid[1]);
kill(pid[1],SIGUSR1);
sleep(1);
printf("parent sending %d SIGUSR2\n",pid[1]);
kill(pid[1],SIGUSR2);
sleep(5);
printf("parent sending %d SIGUSR1\n",pid[1]);
kill(pid[1],SIGUSR1);
sleep(1);
printf("parent sending %d SIGUSR1\n",pid[1]);
kill(pid[1],SIGUSR1);
sleep(1);
printf("parent sending %d SIGINT\n",pid[1]);
kill(pid[1],SIGINT);
exit(0);
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 20:03 ` Steven Rostedt
@ 2005-08-09 20:19 ` Steven Rostedt
2005-08-09 20:49 ` Chris Wright
0 siblings, 1 reply; 36+ messages in thread
From: Steven Rostedt @ 2005-08-09 20:19 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: linux-kernel, Robert Wilkens
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
On Tue, 2005-08-09 at 16:03 -0400, Steven Rostedt wrote:
> Man pages and kernel are right. I just tested this out on 2.6.13-rc3
> with the attached program and it seems to follow what is stated in the
> man pages. So the assumption of what the code did by looking at it
> proves to be the mistake. :-)
>
> Conclusion: sa_mask defers the signals. SA_NODEFER defers the sent
> signal.
I'm the one that's wrong here ;-) OK the kernel _does_ have a bug.
Looking at the code, I now see it, and my last program didn't show it.
The code in question was (as Bodo showed earlier):
if (ret && !(ka->sa.sa_flags & SA_NODEFER)) {
spin_lock_irq(¤t->sighand->siglock);
sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
sigaddset(¤t->blocked,sig);
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
}
Where, sa_mask is _ignored_ if NODEFER is set. (I now have woken up!).
The attached program shows that the sa_mask is indeed ignored when
SA_NODEFER is set.
Now the real question is... Is this a bug?
-- Steve
[-- Attachment #2: signal2 --]
[-- Type: application/x-executable, Size: 9189 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 20:19 ` Steven Rostedt
@ 2005-08-09 20:49 ` Chris Wright
2005-08-09 21:00 ` [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) Steven Rostedt
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Chris Wright @ 2005-08-09 20:49 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Bodo Stroesser, linux-kernel, Robert Wilkens
* Steven Rostedt (rostedt@goodmis.org) wrote:
> Where, sa_mask is _ignored_ if NODEFER is set. (I now have woken up!).
> The attached program shows that the sa_mask is indeed ignored when
> SA_NODEFER is set.
>
> Now the real question is... Is this a bug?
That's not correct w.r.t. SUSv3. sa_mask should be always used and
SA_NODEFER is just whether or not to add that signal in.
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@osdl.org>
---
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(¤t->sighand->siglock);
- sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(¤t->sighand->siglock);
+ sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
+ if (ret && !(ka->sa.sa_flags & SA_NODEFER))
sigaddset(¤t->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(¤t->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(¤t->sighand->siglock);
return ret;
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong)
2005-08-09 20:49 ` Chris Wright
@ 2005-08-09 21:00 ` Steven Rostedt
2005-08-09 21:06 ` Chris Wright
2005-08-09 21:07 ` [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask Steven Rostedt
2005-08-09 21:04 ` Signal handling possibly wrong Chris Wright
2005-08-10 9:11 ` Bodo Stroesser
2 siblings, 2 replies; 36+ messages in thread
From: Steven Rostedt @ 2005-08-09 21:00 UTC (permalink / raw)
To: Chris Wright
Cc: Linus Torvalds, Andrew Morton, Bodo Stroesser, linux-kernel,
Robert Wilkens
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@osdl.org>
> ---
>
> 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(¤t->sighand->siglock);
> - sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
> + spin_lock_irq(¤t->sighand->siglock);
> + sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
> + if (ret && !(ka->sa.sa_flags & SA_NODEFER))
> sigaddset(¤t->blocked,sig);
> - recalc_sigpending();
> - spin_unlock_irq(¤t->sighand->siglock);
> - }
> + recalc_sigpending();
> + spin_unlock_irq(¤t->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@goodmis.org>
--- 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(¤t->sighand->siglock);
sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
- sigaddset(¤t->blocked,sig);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(¤t->blocked,sig);
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 20:49 ` Chris Wright
2005-08-09 21:00 ` [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) Steven Rostedt
@ 2005-08-09 21:04 ` Chris Wright
2005-08-10 9:11 ` Bodo Stroesser
2 siblings, 0 replies; 36+ messages in thread
From: Chris Wright @ 2005-08-09 21:04 UTC (permalink / raw)
To: Chris Wright; +Cc: Steven Rostedt, Bodo Stroesser, linux-kernel, Robert Wilkens
* Chris Wright (chrisw@osdl.org) wrote:
Actually that one broke a fix that I think Brodo discovered in the first
place with bogus stack frames.
Should be this one.
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@osdl.org>
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,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(¤t->sighand->siglock);
sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
- sigaddset(¤t->blocked,sig);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(¤t->blocked,sig);
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong)
2005-08-09 21:00 ` [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) Steven Rostedt
@ 2005-08-09 21:06 ` Chris Wright
2005-08-09 21:07 ` [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask Steven Rostedt
1 sibling, 0 replies; 36+ messages in thread
From: Chris Wright @ 2005-08-09 21:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: Chris Wright, Linus Torvalds, Andrew Morton, Bodo Stroesser,
linux-kernel, Robert Wilkens
* Steven Rostedt (rostedt@goodmis.org) 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!
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-09 21:00 ` [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) Steven Rostedt
2005-08-09 21:06 ` Chris Wright
@ 2005-08-09 21:07 ` Steven Rostedt
2005-08-09 21:27 ` Linus Torvalds
1 sibling, 1 reply; 36+ messages in thread
From: Steven Rostedt @ 2005-08-09 21:07 UTC (permalink / raw)
To: Chris Wright
Cc: gdt, Linus Torvalds, Andrew Morton, Bodo Stroesser, linux-kernel,
Robert Wilkens
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@goodmis.org>
--- 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(¤t->sighand->siglock);
- sigorsets(¤t->blocked,¤t->blocked,&ka.sa.sa_mask);
+ spin_lock_irq(¤t->sighand->siglock);
+ sigorsets(¤t->blocked,¤t->blocked,&ka.sa.sa_mask);
+ if (!(ka.sa.sa_flags & SA_NODEFER))
sigaddset(¤t->blocked, signr);
- recalc_sigpending();
- spin_unlock_irq(¤t->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(¤t->sighand->siglock);
return 1;
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-09 21:07 ` [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask Steven Rostedt
@ 2005-08-09 21:27 ` Linus Torvalds
2005-08-10 3:10 ` Steven Rostedt
2005-08-10 9:44 ` Bodo Stroesser
0 siblings, 2 replies; 36+ messages in thread
From: Linus Torvalds @ 2005-08-09 21:27 UTC (permalink / raw)
To: Steven Rostedt
Cc: Chris Wright, gdt, Andrew Morton, Bodo Stroesser, linux-kernel,
Robert Wilkens
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: smbus driver for ati xpress 200m
2005-08-09 18:50 ` smbus driver for ati xpress 200m yhlu
@ 2005-08-09 22:57 ` Andi Kleen
2005-08-10 2:51 ` yhlu
0 siblings, 1 reply; 36+ messages in thread
From: Andi Kleen @ 2005-08-09 22:57 UTC (permalink / raw)
To: yhlu; +Cc: Andi Kleen, linux-kernel
On Tue, Aug 09, 2005 at 11:50:53AM -0700, yhlu wrote:
> anyone is working on add driver for ati xpress 200m?
>
> without that My turion notebook, can not work read the battery status.
Normally this should be done in ACPI battery.c
-Andi
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: smbus driver for ati xpress 200m
2005-08-09 22:57 ` Andi Kleen
@ 2005-08-10 2:51 ` yhlu
2005-08-10 7:27 ` Andi Kleen
0 siblings, 1 reply; 36+ messages in thread
From: yhlu @ 2005-08-10 2:51 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
yhlunb:/proc/acpi/battery/BAT1 # cat info
present: yes
design capacity: 4800 mAh
last full capacity: 4435 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 300 mAh
design capacity low: 132 mAh
capacity granularity 1: 32 mAh
capacity granularity 2: 32 mAh
model number: ZF02
serial number: 836
battery type: LION
OEM info: SIMPLO
yhlunb:/proc/acpi/battery/BAT1 # cat state
present: yes
ERROR: Unable to read battery status
On 8/9/05, Andi Kleen <ak@suse.de> wrote:
> On Tue, Aug 09, 2005 at 11:50:53AM -0700, yhlu wrote:
> > anyone is working on add driver for ati xpress 200m?
> >
> > without that My turion notebook, can not work read the battery status.
>
> Normally this should be done in ACPI battery.c
>
> -Andi
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-09 21:27 ` Linus Torvalds
@ 2005-08-10 3:10 ` Steven Rostedt
2005-08-10 3:33 ` Steven Rostedt
2005-08-12 18:37 ` Jan Engelhardt
2005-08-10 9:44 ` Bodo Stroesser
1 sibling, 2 replies; 36+ messages in thread
From: Steven Rostedt @ 2005-08-10 3:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Wright, gdt, Andrew Morton, Bodo Stroesser, linux-kernel,
Robert Wilkens
[-- Attachment #1: Type: text/plain, Size: 3978 bytes --]
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
[-- Attachment #2: test_signal.c --]
[-- Type: text/x-csrc, Size: 3573 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
static int u1;
static int u2;
static void user1(int x)
{
/* for testing against itself */
if (u1)
u2 = 1;
u1 = 1;
sleep(5);
u1 = 0;
}
static void user2(int x)
{
if (u1)
u2 = 1;
}
static void intr(int x)
{
exit(u2);
}
static void start(struct sigaction *act)
{
struct sigaction a;
memset(&a,0,sizeof(a));
a.sa_handler = intr;
if ((sigaction(SIGINT,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
/*
* This is the testing handler
*/
act->sa_handler = user1;
if ((sigaction(SIGUSR1,act,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
a.sa_handler = user2;
if ((sigaction(SIGUSR2,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
for (;;)
;
}
int testsig(struct sigaction *act, int sig1, int sig2)
{
int pid;
int status;
if ((pid = fork()) < 0) {
perror("fork");
} else if (!pid) {
/*
* Test1 sa_mask includes SIGUSR2
*/
start(act);
exit(0);
}
/*
* Send first signal to start the test.
*/
kill(pid,sig1);
/*
* SIGUSR1 sleeps for 5, just sleep for on here
* to make sure the system got it.
*/
sleep(1);
/*
* Send the second signal to the child, to see if
* this wakes it up.
*/
kill(pid,sig2);
sleep(1);
/*
* End the test.
*/
kill(pid,SIGINT);
waitpid(pid,&status,0);
return WEXITSTATUS(status);
}
int main(int argc, char **argv)
{
struct sigaction act;
int ret;
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
if (ret == 1) {
printf("sa_mask does not block other signals\n");
} else if (ret == 0) {
printf("sa_mask blocks other signals\n");
} else {
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR2);
if (ret == 1) {
printf("SA_NODEFER does not block other signals\n");
} else if (ret == 0) {
printf("SA_NODEFER blocks other signals\n");
} else {
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
if (ret == 1) {
printf("SA_NODEFER affects sa_mask\n");
} else if (ret == 0) {
printf("SA_NODEFER does not affect sa_mask\n");
} else {
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
if (ret == 1) {
printf("SA_NODEFER and sa_mask does not block sig\n");
} else if (ret == 0) {
printf("SA_NODEFER and sa_mask blocks sig\n");
} else {
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
ret = testsig(&act,SIGUSR1,SIGUSR1);
if (ret == 1) {
printf("!SA_NODEFER does not block sig\n");
} else if (ret == 0) {
printf("!SA_NODEFER blocks sig\n");
} else {
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR1);
if (ret == 1) {
printf("SA_NODEFER does not block sig\n");
} else if (ret == 0) {
printf("SA_NODEFER blocks sig\n");
} else {
printf("Unknown return code!!\n");
}
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);
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-10 3:10 ` Steven Rostedt
@ 2005-08-10 3:33 ` Steven Rostedt
2005-08-12 18:37 ` Jan Engelhardt
1 sibling, 0 replies; 36+ messages in thread
From: Steven Rostedt @ 2005-08-10 3:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Robert Wilkens, linux-kernel, Bodo Stroesser, Andrew Morton, gdt,
Chris Wright
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
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
[-- Attachment #2: test_signal.c --]
[-- Type: text/x-csrc, Size: 3696 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
static int u1;
static int u2;
static void user1(int x)
{
/* for testing against itself */
if (u1)
u2 = 1;
u1 = 1;
sleep(5);
u1 = 0;
}
static void user2(int x)
{
if (u1)
u2 = 1;
}
static void intr(int x)
{
exit(u2);
}
static void start(struct sigaction *act)
{
struct sigaction a;
memset(&a,0,sizeof(a));
a.sa_handler = intr;
if ((sigaction(SIGINT,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
/*
* This is the testing handler
*/
act->sa_handler = user1;
if ((sigaction(SIGUSR1,act,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
a.sa_handler = user2;
if ((sigaction(SIGUSR2,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
for (;;)
;
}
int testsig(struct sigaction *act, int sig1, int sig2)
{
int pid;
int status;
if ((pid = fork()) < 0) {
perror("fork");
} else if (!pid) {
/*
* Test1 sa_mask includes SIGUSR2
*/
start(act);
exit(0);
}
/*
* Send first signal to start the test.
*/
kill(pid,sig1);
/*
* SIGUSR1 sleeps for 5, just sleep for on here
* to make sure the system got it.
*/
sleep(1);
/*
* Send the second signal to the child, to see if
* this wakes it up.
*/
kill(pid,sig2);
sleep(1);
/*
* End the test.
*/
kill(pid,SIGINT);
waitpid(pid,&status,0);
return WEXITSTATUS(status);
}
int main(int argc, char **argv)
{
struct sigaction act;
int ret;
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("sa_mask blocks other signals\n");
break;
case 1:
printf("sa_mask does not block other signals\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("SA_NODEFER blocks other signals\n");
break;
case 1:
printf("SA_NODEFER does not block other signals\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("SA_NODEFER does not affect sa_mask\n");
break;
case 1:
printf("SA_NODEFER affects sa_mask\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("SA_NODEFER and sa_mask blocks sig\n");
break;
case 1:
printf("SA_NODEFER and sa_mask does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("!SA_NODEFER blocks sig\n");
break;
case 1:
printf("!SA_NODEFER does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("SA_NODEFER blocks sig\n");
break;
case 1:
printf("SA_NODEFER does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("sa_mask blocks sig\n");
break;
case 1:
printf("sa_mask does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
exit(0);
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: smbus driver for ati xpress 200m
2005-08-10 2:51 ` yhlu
@ 2005-08-10 7:27 ` Andi Kleen
0 siblings, 0 replies; 36+ messages in thread
From: Andi Kleen @ 2005-08-10 7:27 UTC (permalink / raw)
To: yhlu; +Cc: Andi Kleen, linux-kernel
On Tue, Aug 09, 2005 at 07:51:53PM -0700, yhlu wrote:
> yhlunb:/proc/acpi/battery/BAT1 # cat info
> present: yes
> design capacity: 4800 mAh
> last full capacity: 4435 mAh
> battery technology: rechargeable
> design voltage: 14800 mV
> design capacity warning: 300 mAh
> design capacity low: 132 mAh
> capacity granularity 1: 32 mAh
> capacity granularity 2: 32 mAh
> model number: ZF02
> serial number: 836
> battery type: LION
> OEM info: SIMPLO
> yhlunb:/proc/acpi/battery/BAT1 # cat state
> present: yes
> ERROR: Unable to read battery status
Contact the ACPI people then. They like getting their reports
in http://bugzilla.kernel.org
-Andi
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-09 20:49 ` Chris Wright
2005-08-09 21:00 ` [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) Steven Rostedt
2005-08-09 21:04 ` Signal handling possibly wrong Chris Wright
@ 2005-08-10 9:11 ` Bodo Stroesser
2005-08-10 16:20 ` Chris Wright
2 siblings, 1 reply; 36+ messages in thread
From: Bodo Stroesser @ 2005-08-10 9:11 UTC (permalink / raw)
To: Chris Wright; +Cc: Steven Rostedt, linux-kernel, Robert Wilkens
Chris Wright wrote:
> * Steven Rostedt (rostedt@goodmis.org) wrote:
>
>>Where, sa_mask is _ignored_ if NODEFER is set. (I now have woken up!).
>>The attached program shows that the sa_mask is indeed ignored when
>>SA_NODEFER is set.
>>
>>Now the real question is... Is this a bug?
>
>
> That's not correct w.r.t. SUSv3. sa_mask should be always used and
> SA_NODEFER is just whether or not to add that signal in.
>
> 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
> --
Yes. That's the difference between kernel and man page, that I've found.
I like the patch, at least the version Steven has sent. But at the end,
others have to decide if kernel or man page should be changed.
BTW: would you please call me Bodo? :-)
Regards
Bodo
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-09 21:27 ` Linus Torvalds
2005-08-10 3:10 ` Steven Rostedt
@ 2005-08-10 9:44 ` Bodo Stroesser
1 sibling, 0 replies; 36+ messages in thread
From: Bodo Stroesser @ 2005-08-10 9:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, Chris Wright, gdt, Andrew Morton, linux-kernel,
Robert Wilkens
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Signal handling possibly wrong
2005-08-10 9:11 ` Bodo Stroesser
@ 2005-08-10 16:20 ` Chris Wright
0 siblings, 0 replies; 36+ messages in thread
From: Chris Wright @ 2005-08-10 16:20 UTC (permalink / raw)
To: Bodo Stroesser; +Cc: Chris Wright, Steven Rostedt, linux-kernel, Robert Wilkens
* Bodo Stroesser (bstroesser@fujitsu-siemens.com) wrote:
> BTW: would you please call me Bodo? :-)
Oops, I can't read! Sorry.
-chris
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-10 3:10 ` Steven Rostedt
2005-08-10 3:33 ` Steven Rostedt
@ 2005-08-12 18:37 ` Jan Engelhardt
2005-08-12 18:45 ` Chris Wright
1 sibling, 1 reply; 36+ messages in thread
From: Jan Engelhardt @ 2005-08-12 18:37 UTC (permalink / raw)
To: Steven Rostedt
Cc: Linus Torvalds, Chris Wright, gdt, Andrew Morton, Bodo Stroesser,
linux-kernel, Robert Wilkens
>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
--
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 18:37 ` Jan Engelhardt
@ 2005-08-12 18:45 ` Chris Wright
2005-08-12 18:59 ` Steven Rostedt
0 siblings, 1 reply; 36+ messages in thread
From: Chris Wright @ 2005-08-12 18:45 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Steven Rostedt, Linus Torvalds, Chris Wright, gdt, Andrew Morton,
Bodo Stroesser, linux-kernel, Robert Wilkens
* Jan Engelhardt (jengelh@linux01.gwdg.de) 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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 18:45 ` Chris Wright
@ 2005-08-12 18:59 ` Steven Rostedt
2005-08-12 19:27 ` Steven Rostedt
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Steven Rostedt @ 2005-08-12 18:59 UTC (permalink / raw)
To: Chris Wright
Cc: Jan Engelhardt, Linus Torvalds, gdt, Andrew Morton,
Bodo Stroesser, linux-kernel, Robert Wilkens
[-- Attachment #1: Type: TEXT/PLAIN, Size: 615 bytes --]
On Fri, 12 Aug 2005, Chris Wright wrote:
> * Jan Engelhardt (jengelh@linux01.gwdg.de) 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
[-- Attachment #2: Type: TEXT/x-csrc, Size: 3904 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
static int u1;
static int u2;
static void user1(int x)
{
/* for testing against itself */
if (u1)
u2 = 1;
u1 = 1;
sleep(5);
u1 = 0;
}
static void user2(int x)
{
if (u1)
u2 = 1;
}
static void intr(int x)
{
exit(u2);
}
static void start(struct sigaction *act)
{
struct sigaction a;
memset(&a,0,sizeof(a));
a.sa_handler = intr;
if ((sigaction(SIGINT,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
/*
* This is the testing handler
*/
act->sa_handler = user1;
if ((sigaction(SIGUSR1,act,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
a.sa_handler = user2;
if ((sigaction(SIGUSR2,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
for (;;)
;
}
int testsig(struct sigaction *act, int sig1, int sig2)
{
int pid;
int status;
if ((pid = fork()) < 0) {
perror("fork");
} else if (!pid) {
/*
* Test1 sa_mask includes SIGUSR2
*/
start(act);
exit(0);
}
/*
* Send first signal to start the test.
*/
kill(pid,sig1);
/*
* SIGUSR1 sleeps for 5, just sleep for on here
* to make sure the system got it.
*/
sleep(1);
/*
* Send the second signal to the child, to see if
* this wakes it up.
*/
kill(pid,sig2);
sleep(1);
/*
* End the test.
*/
kill(pid,SIGINT);
waitpid(pid,&status,0);
return WEXITSTATUS(status);
}
int main(int argc, char **argv)
{
struct sigaction act;
int ret;
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("sa_mask blocks other signals\n");
break;
case 1:
printf("sa_mask does not block other signals\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("SA_NODEFER blocks other signals\n");
break;
case 1:
printf("SA_NODEFER does not block other signals\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("SA_NODEFER does not affect sa_mask\n");
break;
case 1:
printf("SA_NODEFER affects sa_mask\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("SA_NODEFER and sa_mask blocks sig\n");
break;
case 1:
printf("SA_NODEFER and sa_mask does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("!SA_NODEFER blocks sig\n");
break;
case 1:
printf("!SA_NODEFER does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("SA_NODEFER blocks sig\n");
break;
case 1:
printf("SA_NODEFER does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("sa_mask blocks sig\n");
break;
case 1:
printf("sa_mask does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
exit(0);
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 18:59 ` Steven Rostedt
@ 2005-08-12 19:27 ` Steven Rostedt
2005-08-12 19:31 ` Jesper Juhl
2005-08-13 18:47 ` Marc Ballarin
2 siblings, 0 replies; 36+ messages in thread
From: Steven Rostedt @ 2005-08-12 19:27 UTC (permalink / raw)
To: Chris Wright
Cc: Jan Engelhardt, Linus Torvalds, gdt, Andrew Morton,
Bodo Stroesser, linux-kernel, Robert Wilkens
[-- Attachment #1: Type: TEXT/PLAIN, Size: 573 bytes --]
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
[-- Attachment #2: Type: TEXT/x-csrc, Size: 3916 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
static int u1;
static int u2;
static void user1(int x)
{
/* for testing against itself */
if (u1)
u2 = 1;
u1 = 1;
sleep(5);
u1 = 0;
}
static void user2(int x)
{
if (u1)
u2 = 1;
}
static void intr(int x)
{
exit(u2);
}
static void start(struct sigaction *act)
{
struct sigaction a;
memset(&a,0,sizeof(a));
a.sa_handler = intr;
if ((sigaction(SIGINT,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
/*
* This is the testing handler
*/
act->sa_handler = user1;
if ((sigaction(SIGUSR1,act,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
a.sa_handler = user2;
if ((sigaction(SIGUSR2,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
for (;;)
;
}
int testsig(struct sigaction *act, int sig1, int sig2)
{
int pid;
int status;
if ((pid = fork()) < 0) {
perror("fork");
} else if (!pid) {
/*
* Test1 sa_mask includes SIGUSR2
*/
start(act);
exit(0);
}
sleep(1);
/*
* Send first signal to start the test.
*/
kill(pid,sig1);
/*
* SIGUSR1 sleeps for 5, just sleep for on here
* to make sure the system got it.
*/
sleep(1);
/*
* Send the second signal to the child, to see if
* this wakes it up.
*/
kill(pid,sig2);
sleep(1);
/*
* End the test.
*/
kill(pid,SIGINT);
waitpid(pid,&status,0);
return WEXITSTATUS(status);
}
int main(int argc, char **argv)
{
struct sigaction act;
int ret;
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("sa_mask blocks other signals\n");
break;
case 1:
printf("sa_mask does not block other signals\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("SA_NODEFER blocks other signals\n");
break;
case 1:
printf("SA_NODEFER does not block other signals\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("SA_NODEFER does not affect sa_mask\n");
break;
case 1:
printf("SA_NODEFER affects sa_mask\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("SA_NODEFER and sa_mask blocks sig\n");
break;
case 1:
printf("SA_NODEFER and sa_mask does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("!SA_NODEFER blocks sig\n");
break;
case 1:
printf("!SA_NODEFER does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("SA_NODEFER blocks sig\n");
break;
case 1:
printf("SA_NODEFER does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("sa_mask blocks sig\n");
break;
case 1:
printf("sa_mask does not block sig\n");
break;
default:
printf("Unknown return code!!\n");
}
exit(0);
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 18:59 ` Steven Rostedt
2005-08-12 19:27 ` Steven Rostedt
@ 2005-08-12 19:31 ` Jesper Juhl
2005-08-12 21:08 ` Steven Rostedt
2005-08-12 21:53 ` Steven Rostedt
2005-08-13 18:47 ` Marc Ballarin
2 siblings, 2 replies; 36+ messages in thread
From: Jesper Juhl @ 2005-08-12 19:31 UTC (permalink / raw)
To: rostedt
Cc: Chris Wright, Jan Engelhardt, Linus Torvalds, gdt, Andrew Morton,
Bodo Stroesser, linux-kernel, Robert Wilkens
On 8/12/05, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 12 Aug 2005, Chris Wright wrote:
> > * Jan Engelhardt (jengelh@linux01.gwdg.de) 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@gmail.com>
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 19:31 ` Jesper Juhl
@ 2005-08-12 21:08 ` Steven Rostedt
2005-08-14 11:24 ` Jesper Juhl
2005-08-12 21:53 ` Steven Rostedt
1 sibling, 1 reply; 36+ messages in thread
From: Steven Rostedt @ 2005-08-12 21:08 UTC (permalink / raw)
To: Jesper Juhl
Cc: Chris Wright, Jan Engelhardt, Linus Torvalds, gdt, Andrew Morton,
Bodo Stroesser, linux-kernel, Robert Wilkens
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
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
[-- Attachment #2: test_signal.c --]
[-- Type: text/x-csrc, Size: 3770 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
static int u1;
static int u2;
static void user1(int x)
{
/* for testing against itself */
if (u1)
u2 = 1;
u1 = 1;
sleep(5);
u1 = 0;
}
static void user2(int x)
{
if (u1)
u2 = 1;
}
static void intr(int x)
{
exit(u2);
}
static void start(struct sigaction *act)
{
struct sigaction a;
memset(&a,0,sizeof(a));
a.sa_handler = intr;
if ((sigaction(SIGINT,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
/*
* This is the testing handler
*/
act->sa_handler = user1;
if ((sigaction(SIGUSR1,act,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
a.sa_handler = user2;
if ((sigaction(SIGUSR2,&a,NULL)) < 0) {
perror("sigaction");
exit(-1);
}
for (;;)
;
}
int testsig(struct sigaction *act, int sig1, int sig2)
{
int pid;
int status;
if ((pid = fork()) < 0) {
perror("fork");
} else if (!pid) {
/*
* Test1 sa_mask includes SIGUSR2
*/
start(act);
exit(0);
}
sleep(1);
/*
* Send first signal to start the test.
*/
kill(pid,sig1);
/*
* SIGUSR1 sleeps for 5, just sleep for on here
* to make sure the system got it.
*/
sleep(1);
/*
* Send the second signal to the child, to see if
* this wakes it up.
*/
kill(pid,sig2);
sleep(1);
/*
* End the test.
*/
kill(pid,SIGINT);
waitpid(pid,&status,0);
return WEXITSTATUS(status);
}
int main(int argc, char **argv)
{
struct sigaction act;
int ret;
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("sa_mask blocks other signals\n");
break;
case 1:
printf("sa_mask does not block other signals\n");
break;
default:
printf("Unknown return code (%d)!!\n",ret);
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("SA_NODEFER blocks other signals\n");
break;
case 1:
printf("SA_NODEFER does not block other signals\n");
break;
default:
printf("Unknown return code (%d)!!\n",ret);
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR2);
ret = testsig(&act,SIGUSR1,SIGUSR2);
switch (ret) {
case 0:
printf("SA_NODEFER does not affect sa_mask\n");
break;
case 1:
printf("SA_NODEFER affects sa_mask\n");
break;
default:
printf("Unknown return code (%d)!!\n",ret);
}
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("SA_NODEFER and sa_mask blocks sig\n");
break;
case 1:
printf("SA_NODEFER and sa_mask does not block sig\n");
break;
default:
printf("Unknown return code (%d)!!\n",ret);
}
memset(&act,0,sizeof(act));
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("!SA_NODEFER blocks sig\n");
break;
case 1:
printf("!SA_NODEFER does not block sig\n");
break;
default:
printf("Unknown return code (%d)!!\n",ret);
}
memset(&act,0,sizeof(act));
memset(&act,0,sizeof(act));
act.sa_flags |= SA_NODEFER;
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("SA_NODEFER blocks sig\n");
break;
case 1:
printf("SA_NODEFER does not block sig\n");
break;
default:
printf("Unknown return code (%d)!!\n",ret);
}
memset(&act,0,sizeof(act));
sigaddset(&act.sa_mask,SIGUSR1);
ret = testsig(&act,SIGUSR1,SIGUSR1);
switch (ret) {
case 0:
printf("sa_mask blocks sig\n");
break;
case 1:
printf("sa_mask does not block sig\n");
break;
default:
printf("Unknown return code (%d)!!\n",ret);
}
exit(0);
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 19:31 ` Jesper Juhl
2005-08-12 21:08 ` Steven Rostedt
@ 2005-08-12 21:53 ` Steven Rostedt
2005-08-14 22:04 ` Kyle Moffett
1 sibling, 1 reply; 36+ messages in thread
From: Steven Rostedt @ 2005-08-12 21:53 UTC (permalink / raw)
To: Jesper Juhl
Cc: Chris Wright, Jan Engelhardt, Linus Torvalds, Andrew Morton,
Bodo Stroesser, linux-kernel, Robert Wilkens
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
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 18:59 ` Steven Rostedt
2005-08-12 19:27 ` Steven Rostedt
2005-08-12 19:31 ` Jesper Juhl
@ 2005-08-13 18:47 ` Marc Ballarin
2 siblings, 0 replies; 36+ messages in thread
From: Marc Ballarin @ 2005-08-13 18:47 UTC (permalink / raw)
To: rostedt
Cc: chrisw, jengelh, torvalds, gdt, akpm, bstroesser, linux-kernel,
robw
On Fri, 12 Aug 2005 14:59:49 -0400 (EDT)
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 12 Aug 2005, Chris Wright wrote:
> > * Jan Engelhardt (jengelh@linux01.gwdg.de) 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 21:08 ` Steven Rostedt
@ 2005-08-14 11:24 ` Jesper Juhl
0 siblings, 0 replies; 36+ messages in thread
From: Jesper Juhl @ 2005-08-14 11:24 UTC (permalink / raw)
To: Steven Rostedt
Cc: Chris Wright, Jan Engelhardt, Linus Torvalds, gdt, Andrew Morton,
Bodo Stroesser, linux-kernel, Robert Wilkens
On 8/12/05, Steven Rostedt <rostedt@goodmis.org> 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@gmail.com>
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask
2005-08-12 21:53 ` Steven Rostedt
@ 2005-08-14 22:04 ` Kyle Moffett
0 siblings, 0 replies; 36+ messages in thread
From: Kyle Moffett @ 2005-08-14 22:04 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jesper Juhl, Chris Wright, Jan Engelhardt, Linus Torvalds,
Andrew Morton, Bodo Stroesser, linux-kernel, Robert Wilkens
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2005-08-14 22:04 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-09 17:44 Signal handling possibly wrong Bodo Stroesser
2005-08-09 18:26 ` Robert Wilkens
2005-08-09 18:32 ` Bodo Stroesser
2005-08-09 18:39 ` Robert Wilkens
2005-08-09 18:44 ` Bodo Stroesser
2005-08-09 19:04 ` Robert Wilkens
2005-08-09 19:33 ` Steven Rostedt
2005-08-09 19:41 ` Bodo Stroesser
2005-08-09 20:03 ` Steven Rostedt
2005-08-09 20:19 ` Steven Rostedt
2005-08-09 20:49 ` Chris Wright
2005-08-09 21:00 ` [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) Steven Rostedt
2005-08-09 21:06 ` Chris Wright
2005-08-09 21:07 ` [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask Steven Rostedt
2005-08-09 21:27 ` Linus Torvalds
2005-08-10 3:10 ` Steven Rostedt
2005-08-10 3:33 ` Steven Rostedt
2005-08-12 18:37 ` Jan Engelhardt
2005-08-12 18:45 ` Chris Wright
2005-08-12 18:59 ` Steven Rostedt
2005-08-12 19:27 ` Steven Rostedt
2005-08-12 19:31 ` Jesper Juhl
2005-08-12 21:08 ` Steven Rostedt
2005-08-14 11:24 ` Jesper Juhl
2005-08-12 21:53 ` Steven Rostedt
2005-08-14 22:04 ` Kyle Moffett
2005-08-13 18:47 ` Marc Ballarin
2005-08-10 9:44 ` Bodo Stroesser
2005-08-09 21:04 ` Signal handling possibly wrong Chris Wright
2005-08-10 9:11 ` Bodo Stroesser
2005-08-10 16:20 ` Chris Wright
2005-08-09 19:33 ` Jeremy Maitin-Shepard
2005-08-09 18:50 ` smbus driver for ati xpress 200m yhlu
2005-08-09 22:57 ` Andi Kleen
2005-08-10 2:51 ` yhlu
2005-08-10 7:27 ` Andi Kleen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox