From: ebiederm@xmission.com (Eric W. Biederman)
To: Will Deacon <will.deacon@arm.com>
Cc: linux-arch@vger.kernel.org, linux-api@vger.kernel.org,
James Morse <james.morse@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/3] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE
Date: Thu, 08 Mar 2018 16:40:12 -0600 [thread overview]
Message-ID: <87o9jymbsj.fsf@xmission.com> (raw)
In-Reply-To: <20180308171153.GD14918@arm.com> (Will Deacon's message of "Thu, 8 Mar 2018 17:11:53 +0000")
Will Deacon <will.deacon@arm.com> writes:
> On Thu, Mar 01, 2018 at 05:44:07PM +0000, Dave Martin wrote:
>> Currently a SIGFPE delivered in response to a floating-point
>> exception trap may have si_code set to 0 on arm64. As reported by
>> Eric, this is a bad idea since this is the value of SI_USER -- yet
>> this signal is definitely not the result of kill(2), tgkill(2) etc.
>> and si_uid and si_pid make limited sense whereas we do want to
>> yield a value for si_addr (which doesn't exist for SI_USER).
>
> [...]
>
>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
>> index e7226c4..9040038 100644
>> --- a/arch/arm64/kernel/fpsimd.c
>> +++ b/arch/arm64/kernel/fpsimd.c
>> @@ -39,6 +39,7 @@
>> #include <linux/slab.h>
>> #include <linux/sysctl.h>
>>
>> +#include <asm/esr.h>
>> #include <asm/fpsimd.h>
>> #include <asm/cputype.h>
>> #include <asm/simd.h>
>> @@ -867,18 +868,20 @@ asmlinkage void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
>> asmlinkage void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
>> {
>> siginfo_t info;
>> - unsigned int si_code = FPE_FIXME;
>> -
>> - if (esr & FPEXC_IOF)
>> - si_code = FPE_FLTINV;
>> - else if (esr & FPEXC_DZF)
>> - si_code = FPE_FLTDIV;
>> - else if (esr & FPEXC_OFF)
>> - si_code = FPE_FLTOVF;
>> - else if (esr & FPEXC_UFF)
>> - si_code = FPE_FLTUND;
>> - else if (esr & FPEXC_IXF)
>> - si_code = FPE_FLTRES;
>> + unsigned int si_code = FPE_FLTUNK;
>
> Happy to take this patch once the dependency on FPE_FLTUNK in core code is
> resolved.
Would it help for me to take the FPE_FLTUNK patch into my siginfo-next
branch? So that there is a common branch with the code so we don't
need to worry about conflicts. If so I will look at that on Monday.
There is another FPE code that appears to be needed for one of the other
architectures as well. If we can figure out how to head conflicts off
at the pass while everyone is fixing the FPE_FIXME type problems it
might help.
But it is all simple enough I expect a word to the wise when I send
Linus my pull request will be enough to sort things out.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Will Deacon <will.deacon@arm.com>
Cc: Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
James Morse <james.morse@arm.com>
Subject: Re: [PATCH v2 2/3] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE
Date: Thu, 08 Mar 2018 16:40:12 -0600 [thread overview]
Message-ID: <87o9jymbsj.fsf@xmission.com> (raw)
Message-ID: <20180308224012.q0KNC2YkuYoHq3P-6M2EANWvXJMHenkuWmmC-Fw5Aa8@z> (raw)
In-Reply-To: <20180308171153.GD14918@arm.com> (Will Deacon's message of "Thu, 8 Mar 2018 17:11:53 +0000")
Will Deacon <will.deacon@arm.com> writes:
> On Thu, Mar 01, 2018 at 05:44:07PM +0000, Dave Martin wrote:
>> Currently a SIGFPE delivered in response to a floating-point
>> exception trap may have si_code set to 0 on arm64. As reported by
>> Eric, this is a bad idea since this is the value of SI_USER -- yet
>> this signal is definitely not the result of kill(2), tgkill(2) etc.
>> and si_uid and si_pid make limited sense whereas we do want to
>> yield a value for si_addr (which doesn't exist for SI_USER).
>
> [...]
>
>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
>> index e7226c4..9040038 100644
>> --- a/arch/arm64/kernel/fpsimd.c
>> +++ b/arch/arm64/kernel/fpsimd.c
>> @@ -39,6 +39,7 @@
>> #include <linux/slab.h>
>> #include <linux/sysctl.h>
>>
>> +#include <asm/esr.h>
>> #include <asm/fpsimd.h>
>> #include <asm/cputype.h>
>> #include <asm/simd.h>
>> @@ -867,18 +868,20 @@ asmlinkage void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
>> asmlinkage void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
>> {
>> siginfo_t info;
>> - unsigned int si_code = FPE_FIXME;
>> -
>> - if (esr & FPEXC_IOF)
>> - si_code = FPE_FLTINV;
>> - else if (esr & FPEXC_DZF)
>> - si_code = FPE_FLTDIV;
>> - else if (esr & FPEXC_OFF)
>> - si_code = FPE_FLTOVF;
>> - else if (esr & FPEXC_UFF)
>> - si_code = FPE_FLTUND;
>> - else if (esr & FPEXC_IXF)
>> - si_code = FPE_FLTRES;
>> + unsigned int si_code = FPE_FLTUNK;
>
> Happy to take this patch once the dependency on FPE_FLTUNK in core code is
> resolved.
Would it help for me to take the FPE_FLTUNK patch into my siginfo-next
branch? So that there is a common branch with the code so we don't
need to worry about conflicts. If so I will look at that on Monday.
There is another FPE code that appears to be needed for one of the other
architectures as well. If we can figure out how to head conflicts off
at the pass while everyone is fixing the FPE_FIXME type problems it
might help.
But it is all simple enough I expect a word to the wise when I send
Linus my pull request will be enough to sort things out.
Eric
next prev parent reply other threads:[~2018-03-08 22:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 17:44 [PATCH v2 0/3] arm64: Fix invalid si_codes for fault signals Dave Martin
2018-03-01 17:44 ` Dave Martin
2018-03-01 17:44 ` [PATCH v2 1/3] signal: Add FPE_FLTUNK si_code for undiagnosable fp exceptions Dave Martin
2018-03-01 17:44 ` Dave Martin
2018-03-08 17:11 ` Will Deacon
2018-03-08 17:11 ` Will Deacon
2018-03-08 22:35 ` Eric W. Biederman
2018-03-08 22:35 ` Eric W. Biederman
2018-03-01 17:44 ` [PATCH v2 2/3] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE Dave Martin
2018-03-01 17:44 ` Dave Martin
2018-03-08 17:11 ` Will Deacon
2018-03-08 17:11 ` Will Deacon
2018-03-08 22:40 ` Eric W. Biederman [this message]
2018-03-08 22:40 ` Eric W. Biederman
2018-03-09 13:10 ` Will Deacon
2018-03-09 13:10 ` Will Deacon
2018-03-09 14:25 ` Dave Martin
2018-03-09 14:25 ` Dave Martin
2018-03-15 21:13 ` Eric W. Biederman
2018-03-15 21:13 ` Eric W. Biederman
2018-03-20 10:04 ` Will Deacon
2018-03-20 10:04 ` Will Deacon
2018-03-08 22:37 ` Eric W. Biederman
2018-03-08 22:37 ` Eric W. Biederman
2018-03-01 17:44 ` [PATCH v2 3/3] arm64: signal: Ensure si_code is valid for all fault signals Dave Martin
2018-03-01 17:44 ` Dave Martin
2018-03-08 16:37 ` Will Deacon
2018-03-08 16:37 ` Will Deacon
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=87o9jymbsj.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=Dave.Martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will.deacon@arm.com \
/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