Re: [PATCH v2 2/2] compiler-gcc: Remove obsolete RELOC_HIDE() macro
From: Uros Bizjak
Date: Sat Sep 05 2026 - 05:42:50 EST
On Fri, Sep 4, 2026 at 5:40 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, 4 Sept 2026 at 08:30, Uros Bizjak <ubizjak@xxxxxxxxx> 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.