> * Steven Rostedt ([EMAIL PROTECTED]) 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. S
* Bodo Stroesser ([EMAIL PROTECTED]) wrote:
> BTW: would you please call me Bodo? :-)
Oops, I can't read! Sorry.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-
Chris Wright wrote:
* Steven Rostedt ([EMAIL PROTECTED]) 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. S
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> Hmm, I think you want this patch. You still need to check the return of
> setting up the frames.
Indeed, I noticecd just after I sent, and sent an updated patch.
Thanks Steve!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
* Chris Wright ([EMAIL PROTECTED]) 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 inappr
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
>
* Steven Rostedt ([EMAIL PROTECTED]) 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 s
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.
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 s
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 sayi
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 pag
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 i
[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-lis
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
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 rat
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
> 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 signa
17 matches
Mail list logo
