Re: [PATCH bpf-next v7 06/11] libbpf: Add support for global percpu data

[Leon Hwang <leon.hwang@linux.dev>]

On 24/6/26 06:45, Andrii Nakryiko wrote:
> On Mon, Jun 22, 2026 at 7:37 AM Leon Hwang <leon.hwang@linux.dev> wrote:
[...]
>> @@ -5353,6 +5387,13 @@ bpf_object__populate_internal_map(struct bpf_object *obj, struct bpf_map *map)
>>                         return err;
>>                 }
>>                 map->mmaped = mmaped;
>> +       } else if (is_percpu) {
>> +               if (mprotect(map->mmaped, mmap_sz, PROT_READ)) {
>> +                       err = -errno;
>> +                       pr_warn("map '%s': failed to mprotect() contents: %s\n",
>> +                               bpf_map__name(map), errstr(err));
>> +                       return err;
>> +               }
> 
> hm... do we need to do this? what happens for LIBBPF_MAP_KCONFIG, do
> we just null out the initial image? should we just do that here?
> Basically what I am asking is how important it is to access initial
> per-CPU image after load? What's the realistic use case for that?
> 

This was suggested by you in v3:
https://lore.kernel.org/bpf/CAEf4BzY9KeVeo2+6Ht1v3rL6UdwNxABZCSK1OZ_sD8qhpYZaeQ@mail.gmail.com/

>>         } else if (map->mmaped) {
>>                 munmap(map->mmaped, mmap_sz);
>>                 map->mmaped = NULL;
>> @@ -10806,16 +10847,19 @@ int bpf_map__fd(const struct bpf_map *map)
>>
>>  static bool map_uses_real_name(const struct bpf_map *map)
>>  {
>> -       /* Since libbpf started to support custom .data.* and .rodata.* maps,
>> -        * their user-visible name differs from kernel-visible name. Users see
>> -        * such map's corresponding ELF section name as a map name.
>> -        * This check distinguishes .data/.rodata from .data.* and .rodata.*
>> -        * maps to know which name has to be returned to the user.
>> +       /*
>> +        * Since libbpf started to support custom .data.*, .rodata.* and
>> +        * .percpu.* maps, their user-visible name differs from
>> +        * kernel-visible name. Users see such map's corresponding ELF section
>> +        * name as a map name. This check distinguishes plain .data/.rodata/.percpu
>> +        * from .data.*, .rodata.* and .percpu.* to choose which name to return.
>>          */
>>         if (map->libbpf_type == LIBBPF_MAP_DATA && strcmp(map->real_name, DATA_SEC) != 0)
>>                 return true;
>>         if (map->libbpf_type == LIBBPF_MAP_RODATA && strcmp(map->real_name, RODATA_SEC) != 0)
>>                 return true;
>> +       if (map->libbpf_type == LIBBPF_MAP_PERCPU && strcmp(map->real_name, PERCPU_SEC) != 0)
>> +               return true;
> 
> um... this is extra logic for DATA/RODATA is supposed to be backwards
> compatible legacy stuff. We shouldn't need this for PERCPU_SEC. It
> should actually be called just ".percpu", not "<object_name>.percpu".
> 
Understand the backwards compatibility after reading the comment in
internal_map_name().

Will drop this hunk, and set "map->name" as ".percpu" in
bpf_object__init_internal_map().

Thanks,
Leon