All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Robert Wilkens <robw@optonline.net>
Cc: linux-kernel@vger.kernel.org,
	Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Subject: Re: Signal handling possibly wrong
Date: Tue, 09 Aug 2005 15:33:03 -0400	[thread overview]
Message-ID: <1123615983.18332.194.camel@localhost.localdomain> (raw)
In-Reply-To: <1123614253.3167.18.camel@localhost.localdomain>

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


  reply	other threads:[~2005-08-09 19:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-09 17:44 Signal handling possibly wrong Bodo Stroesser
2005-08-09 18:26 ` Robert Wilkens
2005-08-09 18:32   ` Bodo Stroesser
2005-08-09 18:39     ` Robert Wilkens
2005-08-09 18:44       ` Bodo Stroesser
2005-08-09 19:04         ` Robert Wilkens
2005-08-09 19:33           ` Steven Rostedt [this message]
2005-08-09 19:41             ` Bodo Stroesser
2005-08-09 20:03               ` Steven Rostedt
2005-08-09 20:19                 ` Steven Rostedt
2005-08-09 20:49                   ` Chris Wright
2005-08-09 21:00                     ` [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) Steven Rostedt
2005-08-09 21:06                       ` Chris Wright
2005-08-09 21:07                       ` [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask Steven Rostedt
2005-08-09 21:27                         ` Linus Torvalds
2005-08-10  3:10                           ` Steven Rostedt
2005-08-10  3:33                             ` Steven Rostedt
2005-08-12 18:37                             ` Jan Engelhardt
2005-08-12 18:45                               ` Chris Wright
2005-08-12 18:59                                 ` Steven Rostedt
2005-08-12 19:27                                   ` Steven Rostedt
2005-08-12 19:31                                   ` Jesper Juhl
2005-08-12 21:08                                     ` Steven Rostedt
2005-08-14 11:24                                       ` Jesper Juhl
2005-08-12 21:53                                     ` Steven Rostedt
2005-08-14 22:04                                       ` Kyle Moffett
2005-08-13 18:47                                   ` Marc Ballarin
2005-08-10  9:44                           ` Bodo Stroesser
2005-08-09 21:04                     ` Signal handling possibly wrong Chris Wright
2005-08-10  9:11                     ` Bodo Stroesser
2005-08-10 16:20                       ` Chris Wright
2005-08-09 19:33           ` Jeremy Maitin-Shepard
2005-08-09 18:50 ` smbus driver for ati xpress 200m yhlu
2005-08-09 22:57   ` Andi Kleen
2005-08-10  2:51     ` yhlu
2005-08-10  7:27       ` Andi Kleen
     [not found] <11855.1123690475@www37.gmx.net>
2005-08-10 16:22 ` Signal handling possibly wrong Michael Kerrisk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1123615983.18332.194.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=bstroesser@fujitsu-siemens.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robw@optonline.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.