David Miller <davem@xxxxxxxxxxxxx> writes: > From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > Date: Fri, 30 Jun 2017 07:39:01 -0500 > >> diff --git a/arch/sparc/include/uapi/asm/siginfo.h b/arch/sparc/include/uapi/asm/siginfo.h >> index 2d9b79ccaa50..6bc5c677e92f 100644 >> --- a/arch/sparc/include/uapi/asm/siginfo.h >> +++ b/arch/sparc/include/uapi/asm/siginfo.h >> @@ -17,6 +17,11 @@ >> #define SI_NOINFO 32767 /* no information in siginfo_t */ >> >> /* >> + * SIGFPE si_codes >> + */ >> +#define FPE_FIXME (__SI_FAULT|0) /* Broken dup of SI_USER */ >> + >> +/* >> * SIGEMT si_codes >> */ >> #define EMT_TAGOVF (__SI_FAULT|1) /* tag overflow */ > > It's one thing to say FIXME in a comment in a kernel local header or > C file. > > It's quite another to put this into the name of a macro which has > visibility in the global user compilation namespace. > > I don't think you should really do that. Good point. Sigh. It almost fits because we did do something off in the uapi exported to userspace and we don't have a header file definition for that case. Still. At this point arch/sparc/include/asm/siginfo.h is a better fit for that definition. I will respin and fix that. I wish I knew what would make a better default floating point si_code on sparc. Using 0 aka SI_USER is doesn't fit at all. Sigh. Unfortunately I don't know the architecture well enough to even guess what is going on in do_fpe_common when when no bits in fsr are set. Any suggests for a better fix than just documenting that linux does something weird and ill advised here? Eric
