The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Quentin Monnet <qmo@kernel.org>
To: Leon Hwang <leon.hwang@linux.dev>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	Jiri Olsa <jolsa@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	kernel-patches-bot@fb.com
Subject: Re: [PATCH bpf-next v8 5/9] bpftool: Generate skeleton for global percpu data
Date: Thu, 2 Jul 2026 11:14:06 +0100	[thread overview]
Message-ID: <80fd18b5-dc4d-4078-a236-80b8be531e22@kernel.org> (raw)
In-Reply-To: <ad19d283-aaab-41f1-b1a5-73de551b03a9@linux.dev>

2026-07-02 14:24 UTC+0800 ~ Leon Hwang <leon.hwang@linux.dev>
> On 2/7/26 03:32, Andrii Nakryiko wrote:
>> On Wed, Jul 1, 2026 at 9:49 AM Quentin Monnet <qmo@kernel.org> wrote:
>>>
>>> 2026-06-29 23:24 UTC+0800 ~ Leon Hwang <leon.hwang@linux.dev>
> [...]
>>>> @@ -254,6 +254,20 @@ static const struct btf_type *find_type_for_map(struct btf *btf, const char *map
>>>>       return NULL;
>>>>  }
>>>>
>>>> +static bool bpf_map_is_skel_data(const struct bpf_map *map)
>>>> +{
>>>> +     if (!bpf_map__is_internal(map))
>>>> +             return false;
>>>> +
>>>> +     if (bpf_map__map_flags(map) & BPF_F_MMAPABLE)
>>>> +             return true;
>>>> +
>>>> +     if (bpf_map__type(map) == BPF_MAP_TYPE_PERCPU_ARRAY)
>>>> +             return true;
>>>> +
>>>> +     return false;
>>>> +}
>>>> +
>>>>  static bool is_mmapable_map(const struct bpf_map *map, char *buf, size_t sz)
>>>>  {
>>>>       size_t tmp_sz;
>>>> @@ -263,7 +277,7 @@ static bool is_mmapable_map(const struct bpf_map *map, char *buf, size_t sz)
>>>>               return true;
>>>>       }
>>>>
>>>> -     if (!bpf_map__is_internal(map) || !(bpf_map__map_flags(map) & BPF_F_MMAPABLE))
>>>> +     if (!bpf_map_is_skel_data(map))
>>>>               return false;
>>>>
>>>>       if (!get_map_ident(map, buf, sz))
>>>
>>>
>>> Thanks! The bpftool patch looks good, with one reservation: after this
>>> patch, I believe "is_mmapable_map(map, ...)" will return true if map is
>>> a percpu map, although percpu maps aren't mmap-able, so we should
>>> probably update the name of that function to avoid any confusion?
>>>
>>
>> Great observation, Quentin!
>>
>> bpf_map_is_skel_data() I think was supposed to be exactly that generic
>> name. But it seems like Leon went half-way through with unification.
>> Unless there are some subtle situations where per-cpu array shouldn't
>> be handled where is_mmapable_map() is handled, we should rename
>> is_mmapable_map() and add BPF_MAP_TYPE_PERCPU_ARRAY check (assuming
>> it's internal map, of course) there.
>>
>> Leon, can you please check?
>>
> Aha, my bad.
> 
> Try to rename is_mmapable_map() to bpf_map_is_skel_data(). See below patch.
> 
> Thanks,
> Leon
> 
> ---
> 
> From 654306cd9091a175883dd61c7b251996c42e7cae Mon Sep 17 00:00:00 2001
> From: Leon Hwang <leon.hwang@linux.dev>
> Date: Mon, 29 Jun 2026 23:24:02 +0800
> Subject: [PATCH bpf-next v9 5/9] bpftool: Generate skeleton for global
> percpu
>  data
> 

[...]

> diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> index 6ae7262ebe0c..798a34366e08 100644
> --- a/tools/bpf/bpftool/gen.c
> +++ b/tools/bpf/bpftool/gen.c

[...]

> @@ -254,7 +254,7 @@ static const struct btf_type
> *find_type_for_map(struct btf *btf, const char *map
>  	return NULL;
>  }
> 
> -static bool is_mmapable_map(const struct bpf_map *map, char *buf,
> size_t sz)
> +static bool bpf_map_is_skel_data(const struct bpf_map *map, char *buf,
> size_t sz)
>  {


Yes, I think it addresses the issue, thanks! I'd maybe drop the
"bpf_map_" prefix in the function name ("is_skel_data_map()" instead?)
to remain closer to is_mmapable_map(), and to avoid creating confusion
with libbpf functions names, although I don't feel strongly about it.
You can add my ACK to this v9 for the bpftool patch when you repost the
series.

Thanks,
Quentin

  reply	other threads:[~2026-07-02 10:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 15:23 [PATCH bpf-next v8 0/9] bpf: Introduce global percpu data Leon Hwang
2026-06-29 15:23 ` [PATCH bpf-next v8 1/9] bpf: Drop duplicate blank lines in verifier Leon Hwang
2026-06-29 15:23 ` [PATCH bpf-next v8 2/9] bpf: Introduce global percpu data Leon Hwang
2026-07-01 19:31   ` Andrii Nakryiko
2026-07-02  6:15     ` Leon Hwang
2026-06-29 15:24 ` [PATCH bpf-next v8 3/9] libbpf: Probe percpu data feature Leon Hwang
2026-06-29 15:24 ` [PATCH bpf-next v8 4/9] libbpf: Add support for global percpu data Leon Hwang
2026-07-01 19:32   ` Andrii Nakryiko
2026-07-02  6:16     ` Leon Hwang
2026-06-29 15:24 ` [PATCH bpf-next v8 5/9] bpftool: Generate skeleton " Leon Hwang
2026-07-01 16:49   ` Quentin Monnet
2026-07-01 19:32     ` Andrii Nakryiko
2026-07-02  6:24       ` Leon Hwang
2026-07-02 10:14         ` Quentin Monnet [this message]
2026-07-02 14:08           ` Leon Hwang
2026-06-29 15:24 ` [PATCH bpf-next v8 6/9] selftests/bpf: Add tests to verify " Leon Hwang
2026-06-29 15:24 ` [PATCH bpf-next v8 7/9] selftests/bpf: Test direct reading/writing read-only percpu_array map Leon Hwang
2026-06-29 15:24 ` [PATCH bpf-next v8 8/9] selftests/bpf: Test verifier log for global percpu data Leon Hwang
2026-06-29 15:24 ` [PATCH bpf-next v8 9/9] selftests/bpf: Verify bpf_iter " 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=80fd18b5-dc4d-4078-a236-80b8be531e22@kernel.org \
    --to=qmo@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kernel-patches-bot@fb.com \
    --cc=leon.hwang@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=shuah@kernel.org \
    --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