> bpf: Zero-fill other CPUs when BPF_F_CPU creates a per-cpu hash element
>
> pcpu_init_value() initializes the per-cpu area of a newly created
> [lru_]percpu_hash element. The area is recycled, so when the value
> comes from a BPF program (onallcpus == false) it writes the running
> CPU's slot and zeroes the rest.
>
> bpf_percpu_hash_update() passes onallcpus == true, which delegates to
> pcpu_copy_value(). Since BPF_F_CPU was added that writes only the CPU
> named in map_flags when the flag is set, so on the create path the other
> slots keep the recycled element's values:
>
> update(k1, 0xdeadc0de, BPF_F_ALL_CPUS) every CPU holds 0xdeadc0de
> delete(k1) element back on the freelist
> update(k2, 0xc0ffee, BPF_F_CPU | 0) creates, writes CPU 0 only
> lookup(k2) CPU 0 0xc0ffee, rest 0xdeadc0de
>
> Zero-fill the other CPUs on that arm too.
>
> Fixes: c6936161fd55 ("bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for
> percpu_hash and lru_percpu_hash maps")
> Signed-off-by: Donggeun Yoo <[email protected]>
This isn't a bug, but could the sentence starting with "Since BPF_F_CPU
was added..." be split or re-flowed? The construction mixes two
sentence frames ("Since ... was added that writes ... so on the create
path ..."), which makes it harder to parse on a first read.
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35801690900
