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

[Uros Bizjak <ubizjak@gmail.com>]

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.