| 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
| ||
|
Date: Wed, 4 Sep 2019 03:18:04 -0700
From: Mike Travis <mike.travis@....com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Borislav Petkov <bp@...en8.de>,
Dimitri Sivanich <dimitri.sivanich@....com>,
Russ Anderson <russ.anderson@....com>,
Hedi Berriche <hedi.berriche@....com>,
Steve Wahl <steve.wahl@....com>, x86@...nel.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 8/8] x86/platform/uv: Account for UV Hubless in is_uvX_hub
Ops
Hi Christoph,
I can do these and leave some comments as markers to find the code to
remove later. The real problem is uv_mmrs.h is a generated file and the
scripts cannot be easily redone. Basically they copy in the verilog
definition files from the UV HUB design files and create kernel
compatible files that also then generate run-time checking of hardware
specifics like MMR addresses and field definitions. The change to
remove those "is supported defines" takes a higher level process that
cannot be done within this short release cycle. We are racing to
include this support in the next linux release for pending new hardware
introductions.
Also that script is in a state of flux for the next UV arch and
processor updates so changing anything at this moment is highly
disruptive. Is there a specific reason why this UV only code that does
not touch anything else in the kernel and only affects our productivity
and system performance appears to be such a problem with you? And why
now, at this moment, and after 10 years does it suddenly seem so
important? I'm all for clean up but not disruption.
Bottom line, I agree to all these changes and I promise to tend to them
in the next release cycle. But please let us get through this cycle
without this much chaos?
Thanks,
Mike
On 9/3/2019 11:52 PM, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 11:58:49AM -0700, Mike Travis wrote:
>> Those ifdefs are not dead code and are being actively used. Plus UV1
>> support is dead and I think the last running system died about a year ago
>> and no support or parts are available. So undef'ing these macros will
>> simplify and reduce the size of the object code.
>
> I'm not complaining about removing some ifdefs, that is always good.
> I complain about keeping the others that are dead. And if Hub 1 is
> dead please drop all the checks and support code for it.
>
> A patch against current mainline to show what I mean is below.
>
> ---
> From e84506399fa9436d47b33491d3e38e9dc3c718c7 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@....de>
> Date: Tue, 3 Sep 2019 18:05:37 +0200
> Subject: x86/uv: Remove the dead UV?_HUB_IS_SUPPORTED defines
>
> These are always set, so remove them and the dead code for the case
> where they are not defined.
>
> Signed-off-by: Christoph Hellwig <hch@....de>
> ---
> arch/x86/include/asm/uv/uv_hub.h | 38 -------------------------------
> arch/x86/include/asm/uv/uv_mmrs.h | 7 ------
> 2 files changed, 45 deletions(-)
>
> diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
> index 6eed0b379412..f71eb659f0de 100644
> --- a/arch/x86/include/asm/uv/uv_hub.h
> +++ b/arch/x86/include/asm/uv/uv_hub.h
> @@ -229,68 +229,33 @@ static inline struct uv_hub_info_s *uv_cpu_hub_info(int cpu)
> #define UV4_HUB_REVISION_BASE 7
> #define UV4A_HUB_REVISION_BASE 8 /* UV4 (fixed) rev 2 */
>
> -#ifdef UV1_HUB_IS_SUPPORTED
> static inline int is_uv1_hub(void)
> {
> return uv_hub_info->hub_revision < UV2_HUB_REVISION_BASE;
> }
> -#else
> -static inline int is_uv1_hub(void)
> -{
> - return 0;
> -}
> -#endif
>
> -#ifdef UV2_HUB_IS_SUPPORTED
> static inline int is_uv2_hub(void)
> {
> return ((uv_hub_info->hub_revision >= UV2_HUB_REVISION_BASE) &&
> (uv_hub_info->hub_revision < UV3_HUB_REVISION_BASE));
> }
> -#else
> -static inline int is_uv2_hub(void)
> -{
> - return 0;
> -}
> -#endif
>
> -#ifdef UV3_HUB_IS_SUPPORTED
> static inline int is_uv3_hub(void)
> {
> return ((uv_hub_info->hub_revision >= UV3_HUB_REVISION_BASE) &&
> (uv_hub_info->hub_revision < UV4_HUB_REVISION_BASE));
> }
> -#else
> -static inline int is_uv3_hub(void)
> -{
> - return 0;
> -}
> -#endif
>
> /* First test "is UV4A", then "is UV4" */
> -#ifdef UV4A_HUB_IS_SUPPORTED
> static inline int is_uv4a_hub(void)
> {
> return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
> }
> -#else
> -static inline int is_uv4a_hub(void)
> -{
> - return 0;
> -}
> -#endif
>
> -#ifdef UV4_HUB_IS_SUPPORTED
> static inline int is_uv4_hub(void)
> {
> return uv_hub_info->hub_revision >= UV4_HUB_REVISION_BASE;
> }
> -#else
> -static inline int is_uv4_hub(void)
> -{
> - return 0;
> -}
> -#endif
>
> static inline int is_uvx_hub(void)
> {
> @@ -302,10 +267,7 @@ static inline int is_uvx_hub(void)
>
> static inline int is_uv_hub(void)
> {
> -#ifdef UV1_HUB_IS_SUPPORTED
> return uv_hub_info->hub_revision;
> -#endif
> - return is_uvx_hub();
> }
>
> union uvh_apicid {
> diff --git a/arch/x86/include/asm/uv/uv_mmrs.h b/arch/x86/include/asm/uv/uv_mmrs.h
> index 62c79e26a59a..9ee5ed6e8b34 100644
> --- a/arch/x86/include/asm/uv/uv_mmrs.h
> +++ b/arch/x86/include/asm/uv/uv_mmrs.h
> @@ -99,13 +99,6 @@
> #define UV3_HUB_PART_NUMBER_X 0x4321
> #define UV4_HUB_PART_NUMBER 0x99a1
>
> -/* Compat: Indicate which UV Hubs are supported. */
> -#define UV1_HUB_IS_SUPPORTED 1
> -#define UV2_HUB_IS_SUPPORTED 1
> -#define UV3_HUB_IS_SUPPORTED 1
> -#define UV4_HUB_IS_SUPPORTED 1
> -#define UV4A_HUB_IS_SUPPORTED 1
> -
> /* Error function to catch undefined references */
> extern unsigned long uv_undefined(char *str);
>
>
Powered by blists - more mailing lists