public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Arch Mailing List <linux-arch@vger.kernel.org>
Subject: Multiple math errors and SIGFPE
Date: Mon, 22 Dec 2008 08:28:42 -0800	[thread overview]
Message-ID: <494FC03A.3090208@zytor.com> (raw)

I have received a bug report related to the si_code field of siginfo for
SIGFPE.  The FPE_ values are (unfortunately) an enumeration rather than
a bitmask, so we can't just OR them together.  Unfortunately when we get
multiple unmasked exceptions at least on x86 we leave info.si_code to
__SI_FAULT, which means it is returned to userspace as zero.  This
violates POSIX, which states that an si_code <= 0 is a user-generated
signal.

Looking at the code in other architectures, it looks like most of them
prioritize the faults, but still end up with __SI_FAULT|0 if none of the
expected conditions are found (which may not be possible, of course.)
Prioritizing the faults seem like the reasonable thing to do in terms of
 dealing with the multiple unmasked errors problem.

I am wondering if it would make sense to notice the combination
__SI_FAULT|0 or __SI_FAULT and (short)si_code < 0 and force SI_KERNEL
into the user-space code field in the generic code.  I am also wondering
if there is any possibility that there is code out there which relies on
the current, buggy behaviour.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

             reply	other threads:[~2008-12-22 16:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-22 16:28 H. Peter Anvin [this message]
2008-12-22 22:00 ` Multiple math errors and SIGFPE Mikael Pettersson

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=494FC03A.3090208@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --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