public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Maitin-Shepard <jbms@cmu.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: Signal handling possibly wrong
Date: Tue, 09 Aug 2005 15:33:40 -0400	[thread overview]
Message-ID: <87d5omkiqz.fsf@jbms.ath.cx> (raw)
In-Reply-To: <1123614253.3167.18.camel@localhost.localdomain> (Robert Wilkens's message of "Tue, 09 Aug 2005 15:04:13 -0400")

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

  parent 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
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 [this message]
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=87d5omkiqz.fsf@jbms.ath.cx \
    --to=jbms@cmu.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox