public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: ebiederm@xmission•com (Eric W. Biederman)
To: linux-arm-kernel@lists•infradead.org
Subject: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
Date: Sun, 15 Apr 2018 10:22:31 -0500	[thread overview]
Message-ID: <87lgdocx54.fsf@xmission.com> (raw)
In-Reply-To: <20180415131206.GR16141@n2100.armlinux.org.uk> (Russell King's message of "Sun, 15 Apr 2018 14:12:06 +0100")

Russell King - ARM Linux <linux@armlinux•org.uk> writes:

> On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote:
>> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin <Dave.Martin@arm•com> wrote:
>> >
>> > Most uses I've seen do nothing more than use the FPE_xyz value to
>> > format diagnostic messages while dying.  I struggled to find code that
>> > made a meaningful functional decision based on the value, though that's
>> > not proof...
>> 
>> Yeah. I've seen code that cares about SIGFPE deeply, but it's almost
>> invariably about some emulated environment (eg Java VM, or CPU
>> emulation).
>> 
>> And the siginfo data is basically never good enough for those
>> environments anyway on its own, so they will go and look at the actual
>> instruction that caused the fault and the register state instead,
>> because they need *all* the information.
>> 
>> The cases that use si_code are the ones that just trapped signals in
>> order to give a more helpful abort message.
>> 
>> So I could certainly imagine that si_code is actually used by somebody
>> who then decides to actuall act differently on it, but aside from
>> perhaps printing out a different message, it sounds far-fetched.
>
> Okay, in that case let's just use FPE_FLTINV.  That makes the patch
> easily back-portable for stable kernels.

If we want to I don't think  backporting 266da65e9156 ("signal: Add
FPE_FLTUNK si_code for undiagnosable fp exceptions") would be at
all difficult.

What it is changing has been stable for quite a while.  The surroundings
might change and so it might require some trivial manual fixup but I
don't expect any problems.

Not that I want to derail the consensus but if we want to backport
similar fixes for arm64 or the other architectures that wind up using
FPE_FLTUNK for their fix we would need to backport 266da65e9156 anyway.

Eric

  reply	other threads:[~2018-04-15 15:22 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180409152253.GD10489@altlinux.org>
2018-04-12  1:34 ` sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid Dmitry V. Levin
2018-04-12  1:45   ` Linus Torvalds
2018-04-12  9:58   ` Russell King - ARM Linux
2018-04-12 11:03     ` Dmitry V. Levin
2018-04-12 12:19       ` Russell King - ARM Linux
2018-04-12 12:49         ` Dmitry V. Levin
2018-04-12 13:14           ` Russell King - ARM Linux
2018-04-12 16:50             ` Linus Torvalds
2018-04-12 17:20               ` Russell King - ARM Linux
2018-04-12 17:22                 ` Linus Torvalds
2018-04-13  9:42                   ` Russell King - ARM Linux
2018-04-13 16:33                     ` Linus Torvalds
2018-04-13 17:08                       ` Dave Martin
2018-04-13 17:54                         ` Russell King - ARM Linux
2018-04-13 18:23                           ` Linus Torvalds
2018-04-13 18:45                             ` Dave Martin
2018-04-13 19:53                               ` Linus Torvalds
2018-04-15 13:12                                 ` Russell King - ARM Linux
2018-04-15 15:22                                   ` Eric W. Biederman [this message]
2018-04-15 15:56                                   ` [RFC PATCH 0/3] Dealing with the aliases of SI_USER Eric W. Biederman
2018-04-15 15:57                                     ` [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized Eric W. Biederman
2018-04-17 13:23                                       ` Dave Martin
2018-04-17 19:37                                         ` Eric W. Biederman
2018-04-18 12:47                                           ` Dave Martin
2018-04-18 14:22                                             ` Eric W. Biederman
2018-04-19  8:26                                               ` Dave Martin
2018-04-15 15:58                                     ` [RFC PATCH 2/3] signal: Reduce copy_siginfo_to_user to just copy_to_user Eric W. Biederman
2018-04-15 15:59                                     ` [RFC PATCH 3/3] signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout Eric W. Biederman
2018-04-15 18:16                                     ` [RFC PATCH 0/3] Dealing with the aliases of SI_USER Linus Torvalds
2018-04-16  2:03                                       ` Eric W. Biederman
2018-04-18 17:58                                       ` Eric W. Biederman
2018-04-19  9:28                                       ` Dave Martin
2018-04-19 14:40                                         ` Eric W. Biederman
2018-04-13 18:35                           ` sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid Dave Martin
2018-04-13 18:50                             ` Russell King - ARM Linux
2018-04-13 18:56                               ` Dave Martin
2018-04-12 17:35               ` Dmitry V. Levin

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=87lgdocx54.fsf@xmission.com \
    --to=ebiederm@xmission$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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