Thread (2 messages) 2 messages, 2 authors, 2018-03-15

Re: [PATCH 12/16] asm-generic: siginfo: remove obsolete #ifdefs

From: Eric W. Biederman <hidden>
Date: 2018-03-15 11:38:43
Also in: lkml

Possibly related (same subject, not in this thread)

Arnd Bergmann [off-list ref] writes:
quoted hunk
On Thu, Mar 15, 2018 at 11:06 AM, Eric W. Biederman
[off-list ref] wrote:
quoted
Arnd Bergmann [off-list ref] writes:
quoted
The frv, tile and blackfin architectures are being removed, so
we can clean up this header by removing all the special cases
except those for ia64.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/uapi/asm-generic/siginfo.h | 36 ++----------------------------------
 1 file changed, 2 insertions(+), 34 deletions(-)
If I am reading siginfo.h correctly after this cleanup patch
we can perform another cleanup and unconditionally define
all of the ia64 si_codes except for __SEGV_PSTKOVF which
aliases SEGV_PKUERR.

Which has the advantage that no one is tempted to define any further
aliased si_codes.
Do you mean like this:

diff --git a/include/uapi/asm-generic/siginfo.h
b/include/uapi/asm-generic/siginfo.h
index b2ebf16c391a..ff13ed50dde8 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -186,11 +186,9 @@ typedef struct siginfo {
 #define ILL_PRVREG     6       /* privileged register */
 #define ILL_COPROC     7       /* coprocessor error */
 #define ILL_BADSTK     8       /* internal stack error */
-#ifdef __ia64__
-# define ILL_BADIADDR  9       /* unimplemented instruction address */
-# define __ILL_BREAK   10      /* illegal break */
-# define __ILL_BNDMOD  11      /* bundle-update (modification) in progress */
-#endif
+#define ILL_BADIADDR   9       /* unimplemented instruction address */
+#define __ILL_BREAK    10      /* illegal break */
+#define __ILL_BNDMOD   11      /* bundle-update (modification) in progress */
 #define NSIGILL                11

 /*
@@ -204,13 +202,11 @@ 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 */
-#ifdef __ia64__
-# define __FPE_DECOVF  9       /* decimal overflow */
-# define __FPE_DECDIV  10      /* decimal division by zero */
-# define __FPE_DECERR  11      /* packed decimal error */
-# define __FPE_INVASC  12      /* invalid ASCII digit */
-# define __FPE_INVDEC  13      /* invalid decimal digit */
-#endif
+#define __FPE_DECOVF   9       /* decimal overflow */
+#define __FPE_DECDIV   10      /* decimal division by zero */
+#define __FPE_DECERR   11      /* packed decimal error */
+#define __FPE_INVASC   12      /* invalid ASCII digit */
+#define __FPE_INVDEC   13      /* invalid decimal digit */
 #define NSIGFPE                13

 /*

That seems reasonable. If you send me a patch with a proper
changelog (I don't think I could explain this well enough), I'll
add it to the series.
Yes.

I just realized you can also remove the #ifdefs for BUS_MCEERR_AR,
BUS_MCEERR_AO, and SEGV_BNDERR.  As those si_codes are now always
defined.  That description I expect you can handle.

For a description of the above change how does this sound?

Unlike system call numbers the assignment of si_codes has never had a
reason to be made per architecture.  Some architectures have had unique
conditions to report and reporting those conditions needed new si_codes.
Nothing has ever needed si_codes to have different values on different
architectures.  The si_code space is vast so even with defining all
si_codes on all architectures there is no danger in running out of
si_code values.

The history of the si_codes BUS_MCEERR_AR, BUS_MCEER_AO, SEGV_BNDERR,
and SEGV_PKUERR show that a need of one architecture frequently becomes
a need of another architecture which makes sharing si_codes between
architectures a positive benefit and something to be encouraged.

Where there are no conflicts with the historical ia64 arch specific
si_codes and any other si_codes make them generic si_codes.  We might
need them on another architecture someday.

This leaves only the good example of arch generic si_codes in the kernel
for future architectures and architecture enhancments to follow.
Without bad examples to follow it should be easy to avoid the mistakes
of the past.

Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help