All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: linux-arch@vger.kernel.org, linux-api@vger.kernel.org,
	James Morse <james.morse@arm.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Catalin Marinas <catalin.marinas@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, 8 Mar 2018 17:11:53 +0000	[thread overview]
Message-ID: <20180308171153.GD14918@arm.com> (raw)
In-Reply-To: <1519926248-12591-3-git-send-email-Dave.Martin@arm.com>

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.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	linux-api@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	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, 8 Mar 2018 17:11:53 +0000	[thread overview]
Message-ID: <20180308171153.GD14918@arm.com> (raw)
Message-ID: <20180308171153.nTxwRNU7GRD_qJQWc6obobwxZjkNrv79UkfaJTo9aTE@z> (raw)
In-Reply-To: <1519926248-12591-3-git-send-email-Dave.Martin@arm.com>

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.

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE
Date: Thu, 8 Mar 2018 17:11:53 +0000	[thread overview]
Message-ID: <20180308171153.GD14918@arm.com> (raw)
In-Reply-To: <1519926248-12591-3-git-send-email-Dave.Martin@arm.com>

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.

Will

  reply	other threads:[~2018-03-08 17:11 UTC|newest]

Thread overview: 41+ 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 ` 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-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-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-01 17:44   ` Dave Martin
2018-03-08 17:11   ` Will Deacon [this message]
2018-03-08 17:11     ` Will Deacon
2018-03-08 17:11     ` Will Deacon
2018-03-08 22:40     ` Eric W. Biederman
2018-03-08 22:40       ` Eric W. Biederman
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 13:10         ` Will Deacon
2018-03-09 14:25         ` Dave Martin
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-15 21:13             ` Eric W. Biederman
2018-03-20 10:04             ` Will Deacon
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-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-01 17:44   ` Dave Martin
2018-03-08 16:37   ` Will Deacon
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=20180308171153.GD14918@arm.com \
    --to=will.deacon@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=ebiederm@xmission.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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.