Re: [PATCH v1 1/2] libbpf: Fix strict aliasing violations in hashmap

[Alexei Starovoitov]

On Sat, Mar 21, 2026 at 4:05 PM Ian Rogers <irogers@xxxxxxxxxx> wrote:
>
> On Sat, Mar 21, 2026 at 12:49 PM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > On Sat, Mar 21, 2026 at 10:37 AM Kumar Kartikeya Dwivedi
> > <memxor@xxxxxxxxx> wrote:
> > >
> > > On Sat, 21 Mar 2026 at 16:42, Yonghong Song <yonghong.song@xxxxxxxxx> wrote:
> > > >
> > > >
> > > >
> > > > On 3/20/26 7:44 PM, Ian Rogers wrote:
> > > > > The hashmap implementation contained strict aliasing violations.
> > > > > Specifically, the hashmap_cast_ptr(p) macro was casting pointers (such
> > > > > as void **) to long *, and these were subsequently dereferenced in
> > > > > functions like hashmap_insert(), hashmap_find(), and hashmap_delete().
> > > > >
> > > > > C's strict aliasing rules (C11 6.5/7) prohibit accessing an object
> > > > > through an lvalue of an incompatible type. Dereferencing a long * to
> > > > > write to a void * object is a violation, even if they share the same
> > > > > size, as they are not compatible types. This can lead to undefined
> > > > > behavior, especially with aggressive compiler optimizations.
> > > >
> > > > Potentially this could be a concern. Did you actually find an issue
> > > > with it?
> > > >
> > > > The linux kernel build has
> > > >     KBUILD_CFLAGS += -fno-strict-aliasing
> > > >
> > > > The libbpf does not have this flag. Maybe we should add '-fno-strict-aliasing'
> > > > for libbpf as well? This way, we can avoid any future potential
> > > > 'strict aliasing' issues.
> > > >
> > > > Note that bpf program (tools/testing/selftests/bpf/Makefile)
> > > > also has '-fno-strict-alaising' flag.
> > > >
> > >
> > > The change itself looks correct to me, fwiw, but as Yonghong said, we
> > > can add -fno-strict-aliasing to CFLAGS and move on. I also doubt the
> > > compiler can cause issues here, since the usage happens in hashmap.c
> > > which wouldn't be visible in other CUs where the call is made and
> > > pointers are passed in (unless compilers also do aliasing-based opts
> > > during LTO). I guess libbpf maintainers can decide what they prefer.
> >
> > Agree. I don't think compilers can misoptimize things here.
> > It's safe to ignore this.
>
> There's LTO support in the Linux tree for tools/perf with the LTO=1
> option [1]. My experience is that it works best with clang and ldd.
> libbpf is statically built into perf by default.
>
> A sashiko review raised the issue when perf was reverting the addition
> of -fno-strict-aliasing, the sashiko review is posted to LKML here:
> https://lore.kernel.org/lkml/CAP-5=fVro6E6fowmmJ7gmKX-5SN8bFU7-5KJk_wFG-bQuVnMHw@xxxxxxxxxxxxxx/
>
> -fno-strict-aliasing was added because some crypto code (copied from
> the kernel) requires it for get/put_unaligned. The fix was to use
> memcpy in the unaligned functions, which they now do [2].
>
> I'd prefer not to hamstring the compiler with -fno-strict-aliasing, we
> have sanitizers that can capture aliasing issues.

We're not going to hack libbpf source or add -fno-strict-aliasing
to Makefile because gemini found a "bug".