A BPF_F_CPU update that creates a [lru_]percpu_hash element writes the named CPU's slot and leaves the others holding the recycled element's values, so a lookup of the new key returns a deleted key's per-cpu values.
Patch 1 zero-fills the other CPUs. Patch 2 adds the selftest: the existing cpu_flag subtests always prime a key with BPF_F_ALL_CPUS first, so the create path is not covered today. v1: https://lore.kernel.org/bpf/[email protected]/ v2: https://lore.kernel.org/bpf/[email protected]/ Changes in v3: - patch 1: key init_cpu on BPF_F_CPU rather than on onallcpus (Leon Hwang) - patch 1: re-flow the paragraph naming pcpu_copy_value() (BPF CI AI review) - patch 2: pin the thread across the delete and the create, and name a CPU other than the pinned one, so the BPF_F_NO_PREALLOC arm does not depend on staying put (BPF CI AI review) Changes in v2: - patch 1: cover the BPF_F_CPU entry condition in the block comment above pcpu_init_value() (BPF CI AI review, Alexei Starovoitov) - patch 2: skip the new subtests instead of failing them on a uniprocessor machine (Sashiko AI review) test_progs -t percpu_alloc and fourteen neighboring map tests, x86_64 under QEMU/KVM, 4 vCPUs: without patch 1 31/112 PASSED, 1/3 FAILED with patch 1 32/115 PASSED, 0/0 FAILED Donggeun Yoo (2): bpf: Zero-fill other CPUs when BPF_F_CPU creates a per-cpu hash element selftests/bpf: Test per-cpu initialization of a BPF_F_CPU created element kernel/bpf/hashtab.c | 11 +- .../selftests/bpf/prog_tests/percpu_alloc.c | 105 ++++++++++++++++++ 2 files changed, 112 insertions(+), 4 deletions(-) -- 2.53.0
