Re: [PATCH bpf-next v5 1/2] bpf: htab: Split htab_elem_lru and htab_elem_pcpu off of htab_elem

[T.J. Mercier]

On Sun, Sep 20, 2026 at 5:51 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Sun, Sep 20, 2026 at 05:22 PM T.J. Mercier <tjmercier@xxxxxxxxxx> wrote:
> > -     if ((u64)attr->key_size + attr->value_size >= KMALLOC_MAX_SIZE -
> > -        sizeof(struct htab_elem))
> > +     if (round_up((u64)attr->key_size, 8) + round_up((u64)attr->value_size, 8) >=
> > +         KMALLOC_MAX_SIZE - sizeof(union htab_elem_all))
>
> sizeof(union htab_elem_all) is the same 48 bytes as before.
> The round_up() part is an unrelated change in what map_create accepts.
> Drop it from this patch.

Ok, but I should do something here. I'll drop the round_up() change
and use sizeof(struct htab_elem_lru) here since it becomes the largest
variant. htab_elem_all was only meant to guard against a future struct
becoming even larger, and without the BUILD_BUG_ON below, union
htab_elem_all isn't guaranteed to have the largest element in it.

> [...]
>
> > +     if (htab_is_lru(htab))
> > +             elem_offset = offsetof(struct htab_elem_lru, elem);
> > +     else if (percpu && !prealloc)
> > +             elem_offset = offsetof(struct htab_elem_pcpu, elem);
> > +
> > +     BUILD_BUG_ON(elem_offset + sizeof(struct htab_elem) >
> > +                  sizeof(union htab_elem_all));
>
> elem_offset is a run-time value. BUILD_BUG_ON() works here only when
> the compiler manages to fold it, and it cannot trigger by construction
> of the union. Drop it.

Yes, it was intentional. Dropping this means we can't have
htab_elem_all in hunk above, so I'll drop the union too.