From nobody Sat Sep 26 05:27:45 2026 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7212C3DA5D6 for ; Fri, 4 Sep 2026 08:28:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788510483; cv=none; b=bMnkwkWyQuVhPeqWvAuXqxfunTKTxxDy/+iXO9KhEDC4s/TueYcQQUBQhXe0mU94vuo8JQAatXWe5wWG5rM2tfteyrFuL57HyTkHuA0dwh3+HOFW2K72xWEnFF5VrRKhLU6GFUqOO6mEDc/pXOJGQrq6IAqJabIuaGA5sqGqwBc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788510483; c=relaxed/simple; bh=TcsW9KgQTWxSQCbb1DnQ1KMc0ofcpqn2+UfH8Sd1f2A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IRmSEmOsHJpBAyP4Rq2h3hh14PnK/QDdGEQD/XFTrUNdmtpnfpJS1RoTNtRfZXWAi2RFJLX3DTh04u2d8ZgN4USqJAl6lB7eVuQnlh7BE145E6tKJ90oJdw49aVZvSvHDm4THiGMx+ikbPLLD1VSBlmxPIABShpk9uS/a0yJX8s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IhPDpJBJ; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IhPDpJBJ" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-484374f54d0so422428f8f.3 for ; Fri, 04 Sep 2026 01:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788510477; x=1789115277; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=BCJR2EnTICH3Aw5ZX+ld9cYG3kFkjVvxy3RdtPuJeNI=; b=IhPDpJBJALstlp4R1P9aLdDu85z9sYOxn4yX8fMOplPCGxhQbk6qpoYYLzg1+OEIYr GQkuHOTTB5/JIhQCTIJGOK4/yphYDQ9KEp1wYmyDo//5NKaSl4jzdGJQtLbeI6TqsNMF qDLq2cenW7dLBIqohHQXlfDMN5mUL3IJxe2p4sns3eXCzDmGfddmWpFrOk1DpRl7/oQ6 bYQ6eQAw1ImdfhxY/6FeUW6BfoI4ZQSr7fGMxqUjEkWP9lNwxQf4M5reCTdPWgMMtz87 o5rodYgVl+I7AfZu7Cf5x4OxZQEfo+lx/ghNdv/dvOhAXiNYTFzQyQc8daMFfJGA0Jw/ wePg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788510477; x=1789115277; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BCJR2EnTICH3Aw5ZX+ld9cYG3kFkjVvxy3RdtPuJeNI=; b=JFPMmgEIeQQkpLs5J+IZvP5RXrXr+MwAtiPo5MhTlcblk02kzIbkq+QUCsaNH3/6tQ UEL3vFtioDisj8SXmft6WjwulGk0D/meXR7y98hf+dq1TZ9y9lEy39WSRx8BokE5DBLJ HNzbygwCl29+LBAFXoZXqeHrfDlFMzSAJdRMSHzSvI1R+vPeVnX3eqURKDdJ4y6V9zWi 8+o8oLj9+F+vTpzsDSKHeg+rUBjgm7Vbif9sjMuI30ro7v6TKmfMlntAqAN+YDl33bzr m65lp95D6MaCkDgvwK23lTX9JcBl1i9mfOwn6uY/wcJqBACSW3LilQgQUgnkEpgZEXpp XScg== X-Forwarded-Encrypted: i=1; AKwUvByO/CUyvPouKnLyXrOBy+MbWkLYylW5bJ0lX7JZZ9PqEYKkPTjDwM+7lqWhWIhATFVKcnwuDoCFz9CzXaY=@vger.kernel.org X-Gm-Message-State: AFuF++nfZEcFKGFb/BMPSOOECy3yzzONlzshue4l+Bbapc2DU0zdhnQA rv9Lt2JMKFu4PIIOb3ehd0MiedBGfTpvlTEZwFOw4dtgfnP6v5kVfj4a X-Gm-Gg: AYBFou0R5MjGoz/lNdJ+0Y+rged3qf6q1Z8S4ztbS6WKSwACILMlxtAXuY/kUKpSOka gXSmEvot6k8jPcYAhZYfU/2f1WrhBbfa6b++uCFfk+a8kP6aBe3oPQC0njXhevlrRMAblwE4gP3 st4a4IuevoUztrBVsvktk5sUlbCA3NwiRUMThAcR4ayVogK8PfgqpdLabG9PLAQf8QYuT/eWA5b S1z8voBh8UuPM4bRPngI7l+AqVFyJzReZAgUZK5GQGIt+/QarrgcnH3gbtZVr/eRC3iIuRpy+g0 Crv2j3dHF2MBA3i8NeCbUVGThjWYQZkjRZXO3jBGwOeDqdKz8N6AVK2/Tlp1MuEZxr871peDqKG qrYvjC9Wo6qrtgao2ZSdoz1fT/0Yn0j5APLyFuIIWrbpP9T78+QywavQ8iNFCNNE3A37pkdU3lh 6Y9tbWb1GCvdKBB+0q0i8Mt/aNQ1rRANqvuqX6sRG2nVhPnisYc+M/E1i6WDNoiaoTZRLoxkjz6 3s8gfOTEvV5Z8zEzx4Att7aYEQhpXb3CkUoR2ZgAZ3viuO2NK9GFsostAxdfsQ1UDnBoA== X-Received: by 2002:a05:6000:25f8:b0:485:78f9:63de with SMTP id ffacd0b85a97d-48586bf7456mr10056913f8f.0.1788510477244; Fri, 04 Sep 2026 01:27:57 -0700 (PDT) Received: from fedora ([193.77.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885cb03asm4556228f8f.37.2026.09.04.01.27.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 01:27:56 -0700 (PDT) From: Uros Bizjak To: x86@kernel.org, linux-kernel@vger.kernel.org Cc: Uros Bizjak , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" Subject: [PATCH v2 1/2] x86/boot: Disable GCC min-pagesize assumption in boot code Date: Fri, 4 Sep 2026 10:25:22 +0200 Message-ID: <20260904082741.578048-2-ubizjak@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904082741.578048-1-ubizjak@gmail.com> References: <20260904082741.578048-1-ubizjak@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable GCC treats absolute addresses smaller than the min-pagesize param (which defaults to 4kB) in the generic address space as presumed results of pointer arithmetics from NULL. For example, the following code, when compiled with -O2 -Warray-bounds (included in -Wall): int foo (void) { return *(int *)0x123; } will emit a rather cryptic warning: warning: array subscript 0 is outside array bounds of =E2=80=98int[0]=E2=80= =99 [-Warray-bounds=3D] 1 | int foo (void) { return *(int *)0x123; } | ^~~~~~~~~~~~~ cc1: note: source object is likely at address zero Currently, the warning is supressed by the GCC specific RELOC_HIDE() macro that obfuscates arithmetic on a variable address so that GCC doesn't recognize the original var, and make assumptions about it. The GCC specific RELOC_HIDE() macro was introduced to work around certain ppc64 specific compiler bug in pre-4.1 GCC. This bug was fixed long ago, and replacing GCC specific macro with a generic one triggers the above warning in boot and realmode source code. The early boot environment does not guarantee any minimum page size, so explicitly setting the minimum page size to zero by adding --param=3Dmin-pagesize=3D0 to the compiler flags when building x86 boot and realmode code with GCC inhibits warnings for addresses below 4kB. The option is guarded by CONFIG_CC_IS_GCC since it is GCC-specific. Signed-off-by: Uros Bizjak Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: "H. Peter Anvin" Acked-by: H. Peter Anvin --- arch/x86/boot/Makefile | 3 +++ arch/x86/realmode/rm/Makefile | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index 3f9fb3698d66..372e67d2a855 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -55,6 +55,9 @@ KBUILD_CFLAGS :=3D $(REALMODE_CFLAGS) -D_SETUP KBUILD_AFLAGS :=3D $(KBUILD_CFLAGS) -D__ASSEMBLY__ KBUILD_CFLAGS +=3D -fno-asynchronous-unwind-tables KBUILD_CFLAGS +=3D $(CONFIG_CC_IMPLICIT_FALLTHROUGH) +ifdef CONFIG_CC_IS_GCC +KBUILD_CFLAGS +=3D $(call cc-option,--param=3Dmin-pagesize=3D0) +endif =20 $(obj)/bzImage: asflags-y :=3D $(SVGA_MODE) =20 diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile index a0fb39abc5c8..75058f4dd7c1 100644 --- a/arch/x86/realmode/rm/Makefile +++ b/arch/x86/realmode/rm/Makefile @@ -67,3 +67,6 @@ KBUILD_CFLAGS :=3D $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \ -I$(srctree)/arch/x86/boot KBUILD_AFLAGS :=3D $(KBUILD_CFLAGS) -D__ASSEMBLY__ KBUILD_CFLAGS +=3D -fno-asynchronous-unwind-tables +ifdef CONFIG_CC_IS_GCC +KBUILD_CFLAGS +=3D $(call cc-option,--param=3Dmin-pagesize=3D0) +endif --=20 2.55.0 From nobody Sat Sep 26 05:27:45 2026 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9694B3EAC61 for ; Fri, 4 Sep 2026 08:28:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788510485; cv=none; b=SR7QTMIOabip55402Mz3qHd8rtxYuyD+tDuzYh5ejHfpCgOPX4tHCFV1cdZlRj5pPI+ty6F5FI87UGPuMl+y7FXwzJ6HAndLd6LP9dSCF0IHCnMhdrJ1+1o1Ayq6T9A5Ki246zkrApQZyn7eTfIMKtUQqIGrmbECdmrsi7baRuw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788510485; c=relaxed/simple; bh=ehf7cibTHV13kn1I4/w1gH3nk2YrtsX5RQWrQhshmiw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QHfbVnYdyux3RHhPFUpp0ap1WSBFqzwTNJOKyj1Gs+SuQTY/2POZZYwN93Sv3Hhgi+vNWqSu6UzebAW0DXtT5z2GuWuxyfBZarFInBcHLluJPKDxEU7Z3CRw16Pl7zXBz9NY8ZB/A5YT53Fx2hoYu6eH9VJ1gYAhKPro+5afYkY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=FEZdgZm3; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FEZdgZm3" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-4843f205a5bso455547f8f.1 for ; Fri, 04 Sep 2026 01:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788510478; x=1789115278; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=qKPV5jw6GtP47CgKC0/pvUAoRdY5Wx++I9+qXsxCWi4=; b=FEZdgZm3oH6vqFMvfwNS4P7r9nnOhhC0NNu46F7uYW5jdGxsIgPQZjT5zf1M8GYkYW BqGtF/8aiZ5fY+E0liPCklFqlU7RvKgh0TmEWD8xsUgmRFz0hecuNVePfwTPabhKIzYa +JWcRMCwJ3z2RCJFBWhmpD/E9Fl2K4nlVs7nuPpdMAQF6KU6okY+2NMctiWLJqkzrbsE 8cjTf9TqFRzq/L+1NnGFn3kxQr4jSjItgSPTOqauU1oJIuQ1YPSl8EGkDOIZvkRG8YUH 2BTD0f+iBzUlpntdPqzSpk3JZSgMypt3ExD1/QD/iX4IdXDGPwtuBbEtRtp6mah1YGjv oZ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788510478; x=1789115278; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=qKPV5jw6GtP47CgKC0/pvUAoRdY5Wx++I9+qXsxCWi4=; b=c3ThHxPcg9dovO5OaOeWFTi9M61TzfhyXlEATIILbO59vSEhOpx0UldKcgVgefLAG3 Asz0luvlJrBUG+sBIJHxgBmHHMxsqwSnF/ScJwcJSdKvI3QqyLcuLa7yRNs4/JvHikHk tlTIHXue+YlT6QfhDmz+JFczotTp82S6a/ZTh+76JKO3s+oQFpU+y7Iha3rWSvb/oY2U YQp9nZF+1Gs/x6lbAL85yEujeXkasiE986P4u1O9+p/CgEvM5B3ZmT+t0kXwWLATDdsH qkOuxHWHLj8kM/z584y8m6RV/Wcw+lQJvnpK8zOgG0H1uZizNKCFMiyTMxQYHLi6X9H+ RaqQ== X-Forwarded-Encrypted: i=1; AKwUvBzCUvGP80FkmuWv3pcCUCRK1MMqrInp0gjUopzfN04ItWnwTjlv9Mr9C1NhcxOixmbdy8xu4pIPtdzlc4w=@vger.kernel.org X-Gm-Message-State: AFuF++m06GVWkpyZOj7ZtzQR55Ziy41eivvxBuNJWnX/ktaJ2Gtd0LzT wFhq1/Ww1RGdb977zuLEiZOx/A2NJ7kdLepEpL+Av7P9ZuF+c6LQB8KK7krOs6eA X-Gm-Gg: AYBFou3QBq8rw+aJAXOgK3AtSHA4QEwD9I+QRmrWiD6r7e+WdNLvwchhD0oDaNJ7feQ CLFR9T5+CnIG9F7TvoUDvC27rmsfsOS5iM2DdgTpR9ZDqJSydZv/T6wAgykqm3/So07YrH8uhqk PIhFyozdNPI+XW/QD1CRUxe+6s0h6Kf4Nsxvwor91g9Xw0CM4ho7J+aA7+P1KO9jOKLv71XbyPb WbvM4LsoZ4V1znWeqazgBmpIkfKgvwrVP5D0oDt+Qxbhd6/SDjw+shYbmMMOBseNzeH0FBnJJKn VvaVTBLjybYLqRSFRDrHzue/JqPXGgMmeXOFWlWEyPp05iWZWmaw+9rwCXv5TW38q/Jj/EbHR/e 6FRTbHQKizNCZgUySNfUYxnuhHWs5euzZdw2hrY0VAr5Y1aZ0RYGGfbUZwZu48muIKqETsO/SMO ffI01tWZZMZuT1Om1rZ/cv7851RZ7ei6/w0mxB5+oWm7GIORqTABy1zS8ok/FUavhUySTZAQObS P6Ai6idMoLwHu8vexZskkTTmYCpmUoJZYn3yJ4gxBgSjDx28TedI486UiWz1ax1KDOFKg== X-Received: by 2002:a05:6000:29dc:b0:482:eadd:174a with SMTP id ffacd0b85a97d-485872a7ef3mr3396378f8f.17.1788510478134; Fri, 04 Sep 2026 01:27:58 -0700 (PDT) Received: from fedora ([193.77.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885cb03asm4556228f8f.37.2026.09.04.01.27.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 01:27:57 -0700 (PDT) From: Uros Bizjak To: x86@kernel.org, linux-kernel@vger.kernel.org Cc: Uros Bizjak , Andrew Morton , Linus Torvalds Subject: [PATCH v2 2/2] compiler-gcc: Remove obsolete RELOC_HIDE() macro Date: Fri, 4 Sep 2026 10:25:23 +0200 Message-ID: <20260904082741.578048-3-ubizjak@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904082741.578048-1-ubizjak@gmail.com> References: <20260904082741.578048-1-ubizjak@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Remove the RELOC_HIDE() macro from include/linux/compiler-gcc.h. The GCC specific macro was historically used to workaround very old compiler bugs (including pre-4.1 ppc64 GCC). These compilers are now long obsolete. Use the generic RELOC_HIDE() macro instead. Removing the GCC specific macro allows the compiler to better optimize the code and results in the following code size reduction for an x86_64 defconfig 7.3-rc1 build: text data bss dec hex filename 29826466 4953091 743828 35523385 21e0b39 vmlinux-ref.o 29821414 4952963 743828 35518205 21df6fd vmlinux-new.o Removing the GCC specific macro also enables the compiler to better analyze the code and avoids suppresion of warnings. Signed-off-by: Uros Bizjak Cc: Andrew Morton Cc: Linus Torvalds --- include/linux/compiler-gcc.h | 25 ------------------------- include/linux/compiler.h | 8 ++++++++ 2 files changed, 8 insertions(+), 25 deletions(-) diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index 5de824a0b3d7..081e658754b9 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -10,31 +10,6 @@ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__) =20 -/* - * This macro obfuscates arithmetic on a variable address so that gcc - * shouldn't recognize the original var, and make assumptions about it. - * - * This is needed because the C standard makes it undefined to do - * pointer arithmetic on "objects" outside their boundaries and the - * gcc optimizers assume this is the case. In particular they - * assume such arithmetic does not wrap. - * - * A miscompilation has been observed because of this on PPC. - * To work around it we hide the relationship of the pointer and the object - * using this macro. - * - * Versions of the ppc64 compiler before 4.1 had a bug where use of - * RELOC_HIDE could trash r30. The bug can be worked around by changing - * the inline assembly constraint from =3Dg to =3Dr, in this particular - * case either is valid. - */ -#define RELOC_HIDE(ptr, off) \ -({ \ - unsigned long __ptr; \ - __asm__ ("" : "=3Dr"(__ptr) : "0"(ptr)); \ - (typeof(ptr)) (__ptr + (off)); \ -}) - #if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__) #define __latent_entropy __attribute__((latent_entropy)) #endif diff --git a/include/linux/compiler.h b/include/linux/compiler.h index cb2f6050bdf7..a44a88236f6c 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -148,6 +148,14 @@ void ftrace_likely_update(struct ftrace_likely_data *f= , int val, =3D (unsigned long)&sym; #endif =20 +/* + * This macro obfuscates arithmetic on a variable address so that the comp= iler + * shouldn't recognize the original var, and make assumptions about it. + * + * This is needed because the C standard makes it undefined to do pointer + * arithmetic on "objects" outside their boundaries and compilers assume + * this is the case. In particular they assume such arithmetic does not wr= ap. + */ #ifndef RELOC_HIDE # define RELOC_HIDE(ptr, off) ((typeof(ptr))((unsigned long)(ptr) + (off))) #endif --=20 2.55.0