[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lgdocx54.fsf@xmission.com>
Date: Sun, 15 Apr 2018 10:22:31 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Dave Martin <Dave.Martin@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Dmitry V. Levin" <ldv@...linux.org>,
sparclinux <sparclinux@...r.kernel.org>,
ppc-dev <linuxppc-dev@...ts.ozlabs.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
Russell King - ARM Linux <linux@...linux.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@....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
Powered by blists - more mailing lists