On 25/6/26 00:45, Andrii Nakryiko wrote:
> On Tue, Jun 23, 2026 at 9:14 PM Leon Hwang <[email protected]> wrote:
>>
>> This was suggested by you in v3:
>> https://lore.kernel.org/bpf/caef4bzy9keveo2+6ht1v3rl6udwnxabzcsk1oz_sd8qhpyz...@mail.gmail.com/
>>
>
> ah, the dangling pointer in skeleton that needs clearing, I forgot
> already :) ok, I don't mind mprotect(), it just was a new case that no
> other map followed, so I was curious if we can avoid deviations. But
> that brings back the KCONFIG map question, can you please check what's
> happening for it? Maybe we should do the same mprotect instead of
> dangling pointer (if we have dangling pointer, of course).
>
Looking at prog_tests/skeleton.c, skel->kconfig is NULL before loading,
then becomes a read-only mmaped pointer after loading.
So, skel->kconfig is not a dangling pointer after loading.
It looks good to mprotect() skel->percpu.
Thanks,
Leon
>>>> } 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)
>>>>
