On Sat, Feb 14, 2026 at 3:54 AM Anand Kumar Shaw <[email protected]> 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
