Hi Dave,
On 21/02/18 16:02, Dave Martin wrote:
> Some architectures cannot always report accurately what kind of
> floating-point exception triggered a floating-point exception trap.
>
> This can occur with fp exceptions occuring on lanes in a vector
(Nit: occurring)
> instruction on arm64 for example.
>
> Rather than have every architecture come up with its own way of
> descrbing such a condition, this patch adds a common FPE_FLTUNK do
(Nits: describing; 'to report')
> report that an fp exception caused a trap but we cannot be certain
> which kind of fp exception it was.
> diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> index 85dc965..10304de 100644
> --- a/include/uapi/asm-generic/siginfo.h
> +++ b/include/uapi/asm-generic/siginfo.h
> @@ -229,7 +229,8 @@ typedef struct siginfo {
> # define __FPE_INVASC 12 /* invalid ASCII digit */
> # define __FPE_INVDEC 13 /* invalid decimal digit */
> #endif
> -#define NSIGFPE 13
> +#define FPE_FLTUNK 14 /* undiagnosed floating-point exception */
> +#define NSIGFPE 14
It looks like x86's compat relies on this value not changing:
| arch/x86/kernel/signal_compat.c: BUILD_BUG_ON(NSIGFPE != 13);
| include/uapi/asm-generic/siginfo.h:#define NSIGFPE 13
(from v4.16-rc2)
Thanks,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
