Re: [RFC PATCH 1/2] arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE

Dave Martin [off-list ref] writes:

On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:

quoted

quoted

diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index e447283..77edb00 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h

@@ -193,7 +193,8 @@ typedef struct siginfo {
 #define FPE_FLTRES	6	/* floating point inexact result */
 #define FPE_FLTINV	7	/* floating point invalid operation */
 #define FPE_FLTSUB	8	/* subscript out of range */
-#define NSIGFPE		8
+#define FPE_UNKNOWN	9	/* undiagnosed floating-point exception */
+#define NSIGFPE		9

Minor nit here.

At least before this is final I would really appreciate if you could
rebase this on top of my unificiation of siginfo.h that I posted on
linux-arch and is in my siginfo-next branch.

As that already pushes NSIGFPE up to 13.

Which would make this patch change NSIGFPE to 14 and allocate the number
14 for FPE_UNKNOWN

My bad -- I hadn't looked in detail at the whole series.

However, the purpose of this as an RFC was to get feedback on whether
adding FPE_UNKNOWN is considered acceptable at all from an API
perspective -- the precise number doesn't matter for that discussion.

Do you have any view on this?

That seems as good a solution as any too me.  It is reality and it
happens in the code and there are several places of the same form I
would use it, just to get rid of the FPE_FIXME.

Eric