linux-kernel - Re: [PATCH 01/12] scripts: subarch.include: fix SUBARCH on MacOS hosts

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: <20240807-mighty-crazy-dove-3dc8a5@lindesnes>
Date: Wed, 7 Aug 2024 17:07:16 +0200
From: Nicolas Schier <nicolas@...sle.eu>
To: da.gomez@...sung.com
Cc: Masahiro Yamada <masahiroy@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Lucas De Marchi <lucas.demarchi@...el.com>,
	Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
	William Hubbs <w.d.hubbs@...il.com>,
	Chris Brannon <chris@...-brannons.com>,
	Kirk Reiser <kirk@...sers.ca>,
	Samuel Thibault <samuel.thibault@...-lyon.org>,
	Paul Moore <paul@...l-moore.com>,
	Stephen Smalley <stephen.smalley.work@...il.com>,
	Ondrej Mosnacek <omosnace@...hat.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org, intel-xe@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org, speakup@...ux-speakup.org,
	selinux@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	kvmarm@...ts.linux.dev, linux-serial@...r.kernel.org,
	llvm@...ts.linux.dev, Finn Behrens <me@...enk.dev>,
	"Daniel Gomez (Samsung)" <d+samsung@...ces.com>,
	gost.dev@...sung.com, Nick Desaulniers <nick.desaulniers@...il.com>
Subject: Re: [PATCH 01/12] scripts: subarch.include: fix SUBARCH on MacOS
 hosts

On Wed, Aug 07, 2024 at 01:09:15AM +0200, Daniel Gomez via B4 Relay wrote:
> From: Nick Desaulniers <nick.desaulniers@...il.com>
> 
> When building the Linux kernel on an aarch64 MacOS based host, if we don't
> specify a value for ARCH when invoking make, we default to arm and thus
> multi_v7_defconfig rather than the expected arm64 and arm64's defconfig.
> 
> This is because subarch.include invokes `uname -m` which on MacOS hosts
> evaluates to `arm64` but on Linux hosts evaluates to `aarch64`,
> 
> This allows us to build ARCH=arm64 natively on MacOS (as in ARCH need
> not be specified on an aarch64-based system).
> 
> Utilize a negative lookahead regular expression to avoid matching arm64.
> 
> Add a separate expression to support for armv.* as per error reported by
> Nicolas Schier [1].
> 
> [1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t
> 
> Signed-off-by: Nick Desaulniers <nick.desaulniers@...il.com>
> Signed-off-by: Daniel Gomez <da.gomez@...sung.com>
> ---
>  scripts/subarch.include | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/subarch.include b/scripts/subarch.include
> index 4bd327d0ae42..5d84ad8c0dee 100644
> --- a/scripts/subarch.include
> +++ b/scripts/subarch.include
> @@ -6,7 +6,8 @@
>  
>  SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
>  				  -e s/sun4u/sparc64/ \
> -				  -e s/arm.*/arm/ -e s/sa110/arm/ \
> +				  -e s/armv.*/arm/ \
> +				  -e s/arm\(?:\(?!64\).*\)/arm/ -e s/sa110/arm/ \
>  				  -e s/s390x/s390/ \
>  				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
>  				  -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> 

Reviewed-by: Nicolas Schier <nicolas@...sle.eu>