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

[ebiederm@xmission.com (Eric W. Biederman)]

Dave Martin <Dave.Martin@arm.com> writes:

> On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
>> 
>> > 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