Re: Signal handling possibly wrong

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

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

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

[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

[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

[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

[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

[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

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

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

> 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

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.