From: Leon Hwang <leon.hwang@linux.dev>
To: Donggeun Yoo <donggeunyoo.kernel@gmail.com>, bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, memxor@gmail.com, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
emil@etsalapatis.com, ihor.solodrai@linux.dev,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf v2 1/2] bpf: Zero-fill other CPUs when BPF_F_CPU creates a per-cpu hash element
Date: Wed, 23 Sep 2026 10:09:40 +0800 [thread overview]
Message-ID: <0a30f489-6771-4798-ab59-b658ef4c24f0@linux.dev> (raw)
In-Reply-To: <20260923000801.1764758-2-donggeunyoo.kernel@gmail.com>
On 23/9/26 08:08, Donggeun Yoo wrote:
> 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 <donggeunyoo.kernel@gmail.com>
> ---
> The merged arm no longer calls bpf_obj_cancel_fields() on the named
> CPU. That call is inert here: it acts only on BPF_TIMER,
> BPF_WORKQUEUE and BPF_TASK_WORK, which map_check_btf() rejects for
> [lru_]percpu_hash.
>
> v2: name the BPF_F_CPU entry condition in the block comment.
>
> kernel/bpf/hashtab.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 4f495dcbf670c..f7a9c432d9b76 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -1054,14 +1054,16 @@ static void pcpu_init_value(struct bpf_htab *htab, void __percpu *pptr,
> /* When not setting the initial value on all cpus, zero-fill element
> * values for other cpus. Otherwise, bpf program has no way to ensure
> * known initial values for cpus other than current one
> - * (onallcpus=false always when coming from bpf prog).
> + * (onallcpus=false always when coming from bpf prog,
> + * map_flags & BPF_F_CPU when coming from syscall but setting
> + * only one cpu).
> */
> - if (!onallcpus) {
> - int current_cpu = raw_smp_processor_id();
> + if (!onallcpus || (map_flags & BPF_F_CPU)) {
> + int init_cpu = onallcpus ? map_flags >> 32 : raw_smp_processor_id();
'onallcpus ? map_flags >> 32' does not look reasonable.
Based on the 'if' above, either of these looks straightforward to me.
int init_cpu = !onallcpus ? raw_smp_processor_id() : map_flags >> 32;
or
int init_cpu = (map_flags & BPF_F_CPU) ? map_flags >> 32 :
raw_smp_processor_id();
Thanks,
Leon
> int cpu;
>
> for_each_possible_cpu(cpu) {
> - if (cpu == current_cpu)
> + if (cpu == init_cpu)
> copy_map_value(&htab->map, per_cpu_ptr(pptr, cpu), value);
> else /* Since elem is preallocated, we cannot touch special fields */
> zero_map_value(&htab->map, per_cpu_ptr(pptr, cpu));
next prev parent reply other threads:[~2026-09-23 2:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 0:07 [PATCH bpf v2 0/2] bpf: fix per-cpu initialization of a BPF_F_CPU created hash element Donggeun Yoo
2026-09-23 0:08 ` [PATCH bpf v2 1/2] bpf: Zero-fill other CPUs when BPF_F_CPU creates a per-cpu " Donggeun Yoo
2026-09-23 0:56 ` bot+bpf-ci
2026-09-24 10:23 ` Donggeun Yoo
2026-09-23 2:09 ` Leon Hwang [this message]
2026-09-24 10:22 ` Donggeun Yoo
2026-09-23 0:08 ` [PATCH bpf v2 2/2] selftests/bpf: Test per-cpu initialization of a BPF_F_CPU created element Donggeun Yoo
2026-09-23 0:56 ` bot+bpf-ci
2026-09-24 10:23 ` Donggeun Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0a30f489-6771-4798-ab59-b658ef4c24f0@linux.dev \
--to=leon.hwang@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=donggeunyoo.kernel@gmail.com \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.