linux-kernel - Re: [PATCH 3/8] signal/sparc: Document a conflict with SI

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: <20170630.124505.736865959393416284.davem@davemloft.net>
Date:   Fri, 30 Jun 2017 12:45:05 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     ebiederm@...ssion.com
Cc:     linux-kernel@...r.kernel.org, luto@...nel.org,
        torvalds@...ux-foundation.org, viro@...iv.linux.org.uk,
        oleg@...hat.com, avagin@...tuozzo.com, tglx@...utronix.de,
        greg@...ah.com, avagin@...nvz.org, serge@...lyn.com,
        xemul@...tuozzo.com, gorcunov@...nvz.org, peterz@...radead.org,
        w@....eu, linux-arch@...r.kernel.org, linux-api@...r.kernel.org,
        containers@...ts.linux-foundation.org, mtk.manpages@...il.com,
        sparclinux@...r.kernel.org
Subject: Re: [PATCH 3/8] signal/sparc: Document a conflict with SI_USER
 with SIGFPE

From: "Eric W. Biederman" <ebiederm@...ssion.com>
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.