Re: [PATCH] bpf: expose original requested max_entries in bpf_map_info

[Alexei Starovoitov]

On Sat, Feb 14, 2026 at 3:54 AM Anand Kumar Shaw
<anandkrshawheritage@xxxxxxxxx> wrote:
>
> When creating LRU hash maps with BPF_F_NO_COMMON_LRU, the kernel
> silently rounds max_entries up to a multiple of num_possible_cpus()
> in htab_map_alloc() to ensure each per-CPU LRU list has at least one
> element. However, the original value requested by the caller is lost --
> map->max_entries is overwritten with the rounded value.
>
> This creates a problem for userspace map managers (e.g., Cilium) that
> reconcile map parameters against their configured values. When the
> kernel-reported max_entries differs from the originally requested value,
> the reconciliation logic detects a "mismatch" and may enter an infinite
> delete-recreate loop, as seen in production incidents where non-power-
> of-2 CPU counts caused small but persistent rounding differences.

Clearly a user space issue.
The kernel side never promised to keep max_entries constant.

pw-bot: cr