bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).