From: "Leon Hwang" <leon.hwang@linux.dev>
To: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>
Cc: <bpf@vger.kernel.org>, <ast@kernel.org>, <andrii@kernel.org>,
<daniel@iogearbox.net>, <jolsa@kernel.org>,
<yonghong.song@linux.dev>, <song@kernel.org>, <eddyz87@gmail.com>,
<dxu@dxuuu.xyz>, <deso@posteo.net>, <kernel-patches-bot@fb.com>
Subject: Re: [PATCH bpf-next v4 2/7] bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags
Date: Wed, 03 Sep 2025 22:26:51 +0800 [thread overview]
Message-ID: <DCJ8H98X6UL4.3O75SJOM2WWRG@linux.dev> (raw)
In-Reply-To: <CAEf4BzaUw868nNG3ngMci4fLPDGsaffQ-O3YrPOEo7N5QEkM_w@mail.gmail.com>
On Thu Aug 28, 2025 at 7:18 AM +08, Andrii Nakryiko wrote:
> On Wed, Aug 27, 2025 at 9:45 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
[...]
>>
>> +#ifdef CONFIG_BPF_SYSCALL
>> +static inline void bpf_percpu_copy_to_user(struct bpf_map *map, void __percpu *pptr, void *value,
>> + u32 size, u64 flags)
>> +{
>> + int current_cpu = raw_smp_processor_id();
>> + int cpu, off = 0;
>> +
>> + if (flags & BPF_F_CPU) {
>> + cpu = flags >> 32;
>> + copy_map_value_long(map, value, cpu != current_cpu ? per_cpu_ptr(pptr, cpu) :
>> + this_cpu_ptr(pptr));
>> + check_and_init_map_value(map, value);
>
> I'm not sure it's the question to you, but why would we
> "check_and_init_map_value" when copying data to user space?... this is
> so confusing...
>
After reading its code, I think it's to hide some kernel details from
user space, e.g. refcount, list nodes, rb nodes.
>> + } else {
>> + for_each_possible_cpu(cpu) {
>> + copy_map_value_long(map, value + off, per_cpu_ptr(pptr, cpu));
>> + check_and_init_map_value(map, value + off);
>> + off += size;
>> + }
>> + }
>> +}
>> +
>> +void bpf_obj_free_fields(const struct btf_record *rec, void *obj);
>> +
>> +static inline void bpf_percpu_copy_from_user(struct bpf_map *map, void __percpu *pptr, void *value,
>> + u32 size, u64 flags)
>> +{
[...]
>> +}
>> +#endif
>
> hm... these helpers are just here with no way to validate that they
> generalize existing logic correctly... Do a separate patch where you
> introduce this helper before adding per-CPU flags *and* make use of
> them in existing code? Then we can check that you didn't introduce any
> subtle differences? Then in this patch you can adjust helpers to
> handle BPF_F_CPU and BPF_F_ALL_CPUS?
>
Get it.
I'll send a separate patch later.
Thanks,
Leon
next prev parent reply other threads:[~2025-09-03 14:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 16:45 [PATCH bpf-next v4 0/7] bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags for percpu maps Leon Hwang
2025-08-27 16:45 ` [PATCH bpf-next v4 1/7] bpf: Introduce internal bpf_map_check_op_flags helper function Leon Hwang
2025-08-27 23:17 ` Andrii Nakryiko
2025-09-03 14:39 ` Leon Hwang
2025-08-27 16:45 ` [PATCH bpf-next v4 2/7] bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags Leon Hwang
2025-08-27 23:18 ` Andrii Nakryiko
2025-09-03 14:26 ` Leon Hwang [this message]
2025-09-03 23:53 ` Andrii Nakryiko
2025-09-04 2:36 ` Leon Hwang
2025-08-27 16:45 ` [PATCH bpf-next v4 3/7] bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags for percpu_array maps Leon Hwang
2025-08-27 16:45 ` [PATCH bpf-next v4 4/7] bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags for percpu_hash and lru_percpu_hash maps Leon Hwang
2025-08-27 23:18 ` Andrii Nakryiko
2025-09-03 14:30 ` Leon Hwang
2025-08-27 16:45 ` [PATCH bpf-next v4 5/7] bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags for percpu_cgroup_storage maps Leon Hwang
2025-08-27 16:45 ` [PATCH bpf-next v4 6/7] libbpf: Support BPF_F_CPU and BPF_F_ALL_CPUS flags for percpu maps Leon Hwang
2025-08-27 23:18 ` Andrii Nakryiko
2025-09-03 14:33 ` Leon Hwang
2025-08-27 16:45 ` [PATCH bpf-next v4 7/7] selftests/bpf: Add cases to test BPF_F_CPU and BPF_F_ALL_CPUS flags Leon Hwang
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=DCJ8H98X6UL4.3O75SJOM2WWRG@linux.dev \
--to=leon.hwang@linux.dev \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=deso@posteo.net \
--cc=dxu@dxuuu.xyz \
--cc=eddyz87@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-patches-bot@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).