On Sun, Nov 9, 2025 at 7:00 PM Алексей Сафин a.safin@rosa.ru wrote:
Thanks for the follow-up.
Just to clarify: the overflow happens before the multiplication by num_entries. In C, the * operator is left-associative, so the expression is evaluated as (value_size * num_possible_cpus()) * num_entries. Since value_size was u32 and num_possible_cpus() returns int, the first product is performed in 32-bit arithmetic due to usual integer promotions. If that intermediate product overflows, the result is already incorrect before it is promoted when multiplied by u64 num_entries.
A concrete example within allowed limits: value_size = 1,048,576 (1 MiB), num_possible_cpus() = 4096 => 1,048,576 * 4096 = 2^32 => wraps to 0 in 32 bits, even with num_entries = 1.
Thank you for the clarification.
Based on my understanding, the maximum value_size for a percpu hashmap appears to be constrained by PCPU_MIN_UNIT_SIZE (32768), as referenced in htab_map_alloc_check():
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/kernel...
This would require num_possible_cpus() to reach 131072 to potentially cause an overflow. However, the maximum number of CPUs supported on x86_64 is typically 8192 in standard kernel configurations. I'm uncertain if any architectures actually support systems at this scale.
This isn’t about a single >4GiB allocation - it’s about aggregated memory usage (percpu), which can legitimately exceed 4GiB in total.
v2 promotes value_size to u64 at declaration, which avoids the 32-bit intermediate overflow cleanly.
-- Regards Yafang