Signal handling possibly wrong

Signal handling possibly wrong

[Bodo Stroesser]

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
  execu­tion 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(&current->sighand->siglock);
                 sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
                 sigaddset(&current->blocked,sig);
                 recalc_sigpending();
                 spin_unlock_irq(&current->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.

Re: Signal handling possibly wrong

[Robert Wilkens]

> 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

Re: Signal handling possibly wrong

[Bodo Stroesser]

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

Re: Signal handling possibly wrong

[Robert Wilkens]

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/

Re: Signal handling possibly wrong

[Bodo Stroesser]

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/

smbus driver for ati xpress 200m

[yhlu]

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

Re: Signal handling possibly wrong

[Robert Wilkens]

[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/

Re: Signal handling possibly wrong

[Steven Rostedt]

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

Re: Signal handling possibly wrong

[Jeremy Maitin-Shepard]

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

Re: Signal handling possibly wrong

[Bodo Stroesser]

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

Re: Signal handling possibly wrong

[Steven Rostedt]

[-- 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);
}

Re: Signal handling possibly wrong

[Steven Rostedt]

[-- 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(&current->sighand->siglock);
                sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
                sigaddset(&current->blocked,sig);
                recalc_sigpending();
                spin_unlock_irq(&current->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 --]

Re: Signal handling possibly wrong

[Chris Wright]

* 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(&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;
 }

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

[Steven Rostedt]

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(&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@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(&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);
 	}

Re: Signal handling possibly wrong

[Chris Wright]

* 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(&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);
 	}

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

[Chris Wright]

* 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!

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

[Steven Rostedt]

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(&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;
 }

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

[Linus Torvalds]

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

Re: smbus driver for ati xpress 200m

[Andi Kleen]

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

Re: smbus driver for ati xpress 200m

[yhlu]

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
>

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

[Steven Rostedt]

[-- 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);
}

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

[Steven Rostedt]

[-- 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);
}

Re: smbus driver for ati xpress 200m

[Andi Kleen]

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

Re: Signal handling possibly wrong

[Bodo Stroesser]

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

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

[Bodo Stroesser]

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

Re: Signal handling possibly wrong

[Chris Wright]

* Bodo Stroesser (bstroesser@fujitsu-siemens.com) wrote:
> BTW: would you please call me Bodo? :-)

Oops, I can't read!  Sorry.
-chris

Re: Signal handling possibly wrong

[Michael Kerrisk]

> * 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.

Yes.

> 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.

It's amazing that this non-conformance was never spotted before.
It seems to go all the way back to kernel 1.0 (when the flag
was known as SA_NOMASK).

I'll get something into the manual pages under BUGS.

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  Grab the latest
tarball at ftp://ftp.win.tue.nl/pub/linux-local/manpages/
and grep the source files for 'FIXME'.

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

[Jan Engelhardt]

>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
-- 

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

[Chris Wright]

* 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.

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

[Steven Rostedt]

[-- 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);
}

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

[Steven Rostedt]

[-- 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);
}

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

[Jesper Juhl]

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

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

[Steven Rostedt]

[-- 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);
}

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

[Steven Rostedt]

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
> 
> 

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

[Marc Ballarin]

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

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

[Jesper Juhl]

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

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

[Kyle Moffett]

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.