David Miller [off-list ref] writes:
From: "Eric W. Biederman" <redacted>
Date: Fri, 30 Jun 2017 07:39:01 -0500
quoted
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