[PATCH v2 0/2] Remove obsolete RELOC_HIDE() macro from compiler-gcc.h

[PATCH v2 0/2] Remove obsolete RELOC_HIDE() macro from compiler-gcc.h

[Uros Bizjak]

The GCC specific macro was historically used to workaround very old
compiler bugs (including pre-4.1 ppc64 GCC). These compilers are long
obsolete.

The generic RELOC_HIDE() macro should be used instead.

The removal causes GCC to detect several reads from addresses below 4kB in
the boot and realmode code. 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 ‘int[0]’ [-Warray-bounds=]
    1 | int foo (void) { return *(int *)0x123; }
      |                         ^~~~~~~~~~~~~
cc1: note: source object is likely at address zero

The early boot environment does not guarantee a minimum page size, so
explicitly setting the minimum page size to zero by adding
--param=min-pagesize=0 to the compiler flags when building the x86
boot and realmode code with GCC inhibits warnings for addresses below 4kB.

A long-term solution is to replace open-coded inline assembly used for
FS/GS memory accesses in arch/x86/boot/ with segment-qualified pointer
dereferences [1]. The compiler allows pointer arithmetic from NULL in
__seg_fs and __seg_gs named address spaces so the --param=min-pagesize=0
parameter is no longer needed.

The v1 patch is available at [2]. v2 leaves the conversion to the __seg_fs
and __seg_gs named address space to follow-up x86 boot code
cleanup patches [1].

[1] https://lore.kernel.org/lkml/20260120195407.1163051-1-hpa@zytor.com/
[2] https://lore.kernel.org/lkml/20251223202038.91200-1-ubizjak@gmail.com/

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>

Uros Bizjak (2):
  x86/boot: Disable GCC min-pagesize assumption in boot code
  compiler-gcc: Remove obsolete RELOC_HIDE() macro

 arch/x86/boot/Makefile        |  3 +++
 arch/x86/realmode/rm/Makefile |  3 +++
 include/linux/compiler-gcc.h  | 25 -------------------------
 include/linux/compiler.h      |  8 ++++++++
 4 files changed, 14 insertions(+), 25 deletions(-)

-- 
2.55.0

[PATCH v2 1/2] x86/boot: Disable GCC min-pagesize assumption in boot code

[Uros Bizjak]

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 ‘int[0]’ [-Warray-bounds=]
    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=min-pagesize=0 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 <ubizjak@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
 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	:= $(REALMODE_CFLAGS) -D_SETUP
 KBUILD_AFLAGS	:= $(KBUILD_CFLAGS) -D__ASSEMBLY__
 KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables
 KBUILD_CFLAGS	+= $(CONFIG_CC_IMPLICIT_FALLTHROUGH)
+ifdef CONFIG_CC_IS_GCC
+KBUILD_CFLAGS	+= $(call cc-option,--param=min-pagesize=0)
+endif
 
 $(obj)/bzImage: asflags-y  := $(SVGA_MODE)
 
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	:= $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \
 		   -I$(srctree)/arch/x86/boot
 KBUILD_AFLAGS	:= $(KBUILD_CFLAGS) -D__ASSEMBLY__
 KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables
+ifdef CONFIG_CC_IS_GCC
+KBUILD_CFLAGS	+= $(call cc-option,--param=min-pagesize=0)
+endif
-- 
2.55.0

Re: [PATCH v2 1/2] x86/boot: Disable GCC min-pagesize assumption in boot code

[H. Peter Anvin]

On September 4, 2026 1:25:22 AM PDT, Uros Bizjak <ubizjak@gmail.com> wrote:
>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 ‘int[0]’ [-Warray-bounds=]
>    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=min-pagesize=0 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 <ubizjak@gmail.com>
>Cc: Thomas Gleixner <tglx@linutronix.de>
>Cc: Ingo Molnar <mingo@kernel.org>
>Cc: Borislav Petkov <bp@alien8.de>
>Cc: Dave Hansen <dave.hansen@linux.intel.com>
>Cc: "H. Peter Anvin" <hpa@zytor.com>
>---
> 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	:= $(REALMODE_CFLAGS) -D_SETUP
> KBUILD_AFLAGS	:= $(KBUILD_CFLAGS) -D__ASSEMBLY__
> KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables
> KBUILD_CFLAGS	+= $(CONFIG_CC_IMPLICIT_FALLTHROUGH)
>+ifdef CONFIG_CC_IS_GCC
>+KBUILD_CFLAGS	+= $(call cc-option,--param=min-pagesize=0)
>+endif
> 
> $(obj)/bzImage: asflags-y  := $(SVGA_MODE)
> 
>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	:= $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \
> 		   -I$(srctree)/arch/x86/boot
> KBUILD_AFLAGS	:= $(KBUILD_CFLAGS) -D__ASSEMBLY__
> KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables
>+ifdef CONFIG_CC_IS_GCC
>+KBUILD_CFLAGS	+= $(call cc-option,--param=min-pagesize=0)
>+endif

That seems like a much better answer than that horrible hack. 

Acked-by: H. Peter Anvin <hpa@zytor.com>

[PATCH v2 2/2] compiler-gcc: Remove obsolete RELOC_HIDE() macro

[Uros Bizjak]

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 <ubizjak@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
---
 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__)
 
-/*
- * 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 =g to =r, in this particular
- * case either is valid.
- */
-#define RELOC_HIDE(ptr, off)						\
-({									\
-	unsigned long __ptr;						\
-	__asm__ ("" : "=r"(__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,
 	= (unsigned long)&sym;
 #endif
 
+/*
+ * This macro obfuscates arithmetic on a variable address so that the compiler
+ * 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 wrap.
+ */
 #ifndef RELOC_HIDE
 # define RELOC_HIDE(ptr, off) ((typeof(ptr))((unsigned long)(ptr) + (off)))
 #endif
-- 
2.55.0

Re: [PATCH v2 2/2] compiler-gcc: Remove obsolete RELOC_HIDE() macro

[Linus Torvalds]

On Fri, 4 Sept 2026 at 01:28, Uros Bizjak <ubizjak@gmail.com> wrote:
>
> 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.

The gcc-4.1 bug in that comment was about how the use of "=g" caused
ppc code generation issues.

It's not entirely clear to me that the original reason for this macro
is actually gone. The cast to 'long' has not always hidden the
provenance of the address.

The use of inline asm in RELOC_HIDE() actually goes back much much further.

I do agree that it probably is no longer relevant, but that commit
message is actively misleading. RELOC_HIDE() itself has nothing to do
with the ppc64-specific gcc bug, that was literally just a small
indepdendent change to the implementation.

              Linus

Re: [PATCH v2 2/2] compiler-gcc: Remove obsolete RELOC_HIDE() macro

[Uros Bizjak]

On Fri, Sep 4, 2026 at 5:16 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, 4 Sept 2026 at 01:28, Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > 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.
>
> The gcc-4.1 bug in that comment was about how the use of "=g" caused
> ppc code generation issues.
>
> It's not entirely clear to me that the original reason for this macro
> is actually gone. The cast to 'long' has not always hidden the
> provenance of the address.
>
> The use of inline asm in RELOC_HIDE() actually goes back much much further.
>
> I do agree that it probably is no longer relevant, but that commit
> message is actively misleading. RELOC_HIDE() itself has nothing to do
> with the ppc64-specific gcc bug, that was literally just a small
> indepdendent change to the implementation.

Oh, now that you point out, I was looking at inline asm, but since the
patch removes GCC specific macro, the commit message reads like the
*macro* is there to workaround very old compiler bugs. It is
effectively inline asm that the patch removes, and as you point out,
this inline asm caused ppc code gen issues. Let me rephrase the commit
message to fix the confusion.

The cast to (unsigned long) should remove all compiler's knowledge
about the pointer and force the compiler to use integer arithmetic
instead of pointer arithmetic. This is what the generic version does
without inline asm.

Uros.


>               Linus

Re: [PATCH v2 2/2] compiler-gcc: Remove obsolete RELOC_HIDE() macro

[Linus Torvalds]

On Fri, 4 Sept 2026 at 08:30, Uros Bizjak <ubizjak@gmail.com> wrote:
>
> The cast to (unsigned long) should remove all compiler's knowledge
> about the pointer and force the compiler to use integer arithmetic
> instead of pointer arithmetic. This is what the generic version does
> without inline asm.

Yes. The question here is that word "should".

It's not clear that it always does, and historically hasn't.

To clarify: I'm not against this patch. But it is potentially
dangerous and could expose things. See for example:

        /* RELOC_HIDE to prevent gcc from warning about short alloc */
        ptr1 = RELOC_HIDE(kmalloc(sizeof(*ptr1) - 3, GFP_KERNEL), 0);
        KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr1);

where RELOC_HIDE() is used to make sure gcc doesn't do certain optimizations.

Is that code pretty or valid? No. But it's an existing example of
people using RELOC_HIDE to hide things from the compiler.

               Linus

Re: [PATCH v2 2/2] compiler-gcc: Remove obsolete RELOC_HIDE() macro

[Uros Bizjak]

On Fri, Sep 4, 2026 at 5:40 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, 4 Sept 2026 at 08:30, Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > The cast to (unsigned long) should remove all compiler's knowledge
> > about the pointer and force the compiler to use integer arithmetic
> > instead of pointer arithmetic. This is what the generic version does
> > without inline asm.
>
> Yes. The question here is that word "should".
>
> It's not clear that it always does, and historically hasn't.
>
> To clarify: I'm not against this patch. But it is potentially
> dangerous and could expose things. See for example:
>
>         /* RELOC_HIDE to prevent gcc from warning about short alloc */
>         ptr1 = RELOC_HIDE(kmalloc(sizeof(*ptr1) - 3, GFP_KERNEL), 0);
>         KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr1);
>
> where RELOC_HIDE() is used to make sure gcc doesn't do certain optimizations.
>
> Is that code pretty or valid? No. But it's an existing example of
> people using RELOC_HIDE to hide things from the compiler.

Yes, this one requires inline asm. The testcase:

--cut here--
void *baz (void)
{
struct {
unsigned long words[2];
} *ptr1;

    /* RELOC_HIDE to prevent gcc from warning about short alloc */
ptr1 = RELOC_HIDE(malloc(sizeof(*ptr1) - 3), 0);

    return ptr1;
}
--cut here--

compiles without warning with the old definition of RELOC_HIDE() and reports:

<source>: In function 'baz':
<source>:33:14: warning: allocation of insufficient size '13' for type
'struct <anonymous>' with size '16' [-Walloc-size]
   33 |         ptr1 = RELOC_HIDE(malloc(sizeof(*ptr1) - 3), 0);
      |              ^

Also, GCC > 4.9 has its share of problems with "=rm" output (e.g.
[1]), so the output asm operand constraint should stay "=r".

So, RELOC_HIDE() should stay as it is, and the patch should simply
remove the obsolete third paragraph from the comment.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124209

Thanks,
Uros.