Re: [PATCH bpf-next v8 2/2] bpf: htab: Reduce elem_size by 8 bytes for small key sizes

[T.J. Mercier]

On Sat, Oct 3, 2026 at 8:41 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Fri, Oct 02, 2026 at 09:17 AM T.J. Mercier <tjmercier@xxxxxxxxxx> wrote:
> > +static __always_inline struct htab_elem *
> > +__lookup_elem_raw(struct bpf_htab *htab, struct hlist_nulls_head *head,
> > +               u32 hash, void *key, u32 key_size,
> > +               struct hlist_nulls_node **out_n)
> >  {
> >       struct hlist_nulls_node *n;
> >       struct htab_elem *l;
> >
> > -     hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
> > -             if (l->hash == hash && !memcmp(&l->key, key, key_size))
> > -                     return l;
> > +     if (htab_has_hash(htab)) {
>
> [...]
>
> > +             unsigned long k = 0;
> > +
> > +             memcpy(&k, key, key_size);
>
> My bot is saying that this will break 32-bit builds with FORTIFY_SOURCE.
> __htab_map_lookup_elem_u64() inlines all of it with key_size == 8.
> has_hash is a run-time load, so the compiler has to keep this branch
> and it's a memcpy of 8 bytes into 4 byte 'k'.
> fortify_memcpy_chk() will hit __write_overflow_field().
> That's a build error in i386 and arm allmodconfig.

I see the build error on 32bit with FORTIFY_SOURCE.

> has_hash is a compile time constant in __htab_map_lookup_elem_u32()
> and _u64(), just like key_size.
> Only htab_map_gen_lookup() emits them, so the map is BPF_MAP_TYPE_HASH,
> never LRU.
> Don't read it from htab in these two.

Ok, sizeof(u32) > sizeof(unsigned long) like in htab_map_alloc()
should do the trick for those two call sites.

Thanks,
T.J.