lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o9jpbmcy.fsf@xmission.com>
Date:   Thu, 15 Mar 2018 06:37:49 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Arnd Bergmann <arnd@...db.de>
Cc:     linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 12/16] asm-generic: siginfo: remove obsolete #ifdefs

Arnd Bergmann <arnd@...db.de> writes:

> On Thu, Mar 15, 2018 at 11:06 AM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> Arnd Bergmann <arnd@...db.de> writes:
>>
>>> 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@...db.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ