On Thu, Aug 13, 2026 at 7:03 PM Leon Hwang <[email protected]> wrote:
>
> On 14/8/26 01:56, Andrii Nakryiko wrote:
> > On Thu, Aug 13, 2026 at 8:24 AM Leon Hwang <[email protected]> wrote:
> [...]
> >> @@ -263,13 +269,24 @@ 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_internal(map))
> >> return false;
> >>
> >> if (!get_map_ident(map, buf, sz))
> >> return false;
> >>
> >> - return true;
> >> + if (bpf_map__map_flags(map) & BPF_F_MMAPABLE)
> >> + return true;
> >> +
> >> + if (bpf_map__type(map) == BPF_MAP_TYPE_PERCPU_ARRAY)
> >> + return bpf_map__btf_value_type_id(map) != 0;
> >
> > why do we need this btf_value_type_id() check? in what case it's
> > expected that there will be no BTF info set?
>
> Add this check by referencing btf_value_type_id check in libbpf's
> map_is_mmapable(). That said, if btf_value_type_id is 0 for
> global/percpu data, is_mmapable_map() should return false for them.
>
> And, if the bpf obj is compiled without -g, this check helps to avoid
> generating struct for percpu data explicitly.
>
I don't think skeleton can be generated if BPF object was compiled
without -g, so let's just drop that btf_value_type_id() check, it
causes more questions than it's actually useful
> Thanks,
> Leon
>
> >
> >> +
> >> + return false;
> >> +}
> >> +
> >> +static bool is_mmapable_map(const struct bpf_map *map, char *buf, size_t
> >> sz)
> >> +{
> >> + return is_skel_data(map, buf, sz) && bpf_map__type(map) !=
> >> BPF_MAP_TYPE_PERCPU_ARRAY;
> >> }
> >>
> >
> > [...]
>
