Re: [Regression] [PATCH v5 2/4] vdso: Switch get/put unaligned from packed struct to memcpy

[Arnd Bergmann]

On Mon, Oct 19, 2026, at 23:14, Ian Rogers wrote:
> On Mon, Oct 19, 2026 at 2:00 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> On Mon, Oct 19, 2026, at 19:04, Ian Rogers wrote:
>
> Is there a reason that the compiler's instruction selection can't make
> the same decision for the memcpy case as the __packed case? We can
> work around the compiler bug with a config option.
> The intent with using __builtin_memcpy, as opposed to memcpy, is to
> avoid a library call.

As far as I understand, the only difference between calling
__builtin_memcpy() and memcpy() is the need for a prototype
for the latter, I would expect the compiler to behave the exact
same for for both otherwise. Whether any of the string.h functions
are replaced by an inline alternative is a complex optimizer
decision, not something you can enforce by calling the function
by one name rather than the other.

If you try this one on riscv64, you will find that both gcc and
clang use the byte-at-a-time version at -O2 but the out-of-line
one for -Os (regardless of __builtin_*):

static inline int f(void *p)
{
    int i;
    __builtin_memcpy(p, &i, sizeof(i));
    return i;
}
int g(int *p)
{
     return f(p);
}

> It looks like all the unaligned code is using void* so I'm not sure
> where the low bit concerns are stemming from. If anything, type
> punning seems to be a worse problem, but the hope is that the __packed
> attribute avoids it. I know this assumption makes compiler people
> uncomfortable and memcpy is their preferred go to.

The problem with the bpf_kfunc_test_uninit_alias() function is that
passing an unaligned pointer into it is undefined behavior, and
the only way I know to make it safe is type-punning to a __packed
pointer in combination with traditional aliasing rules, which
tells the compiler exactly how to access the data behind the
pointer.

Whether memcpy() is strong enough to have the same effect in
that example is something I don't know as I never tried to program
with strict aliasing rules, so maybe I'm just be overly cautious:
The include/linux/unaligned.h functions are all 'inline', so the
compiler still has knowledge about the alignment of the accessed
objects from the caller and with -fstrict-aliasing may be
able to assume that the object is aligned.

        Arnd