Re: [PATCH bpf-next v2 1/3] btf: allow mmap of vmlinux btf

[Lorenz Bauer <lmb@isovalent.com>]

On Fri, May 2, 2025 at 6:15 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> remap_pfn_range() should be avoided.
> See big comment in kernel/events/core.c in map_range().
>
> The following seems to work:

Thanks, this helped a lot.

> but this part is puzzling:
>         trailing = page_size - (btf_size % page_size) % page_size;

The intention is to calculate how many bytes of trailing zeroes to
expect while accounting for the case where btf_size % page_size == 0.
I could replace this with a check

    end = btf_size + (page_size - 1) / page_size * page_size;
    for (i = btf_size; i < end; i++) ...

Better?

In the meantime I've looked at allowing mmap of kmods. I'm not sure
it's worth the effort:

1. Allocations of btf->data in btf_parse_module() would have to use
vmalloc_user() so that allocations are page aligned and zeroed
appropriately. This will be a bit more expensive on systems with large
pages and / or many small kmod BTFs. We could only allow mmap of BTF
>= PAGE_SIZE, at additional complexity.

2. We need to hold a refcount on struct btf for each mmapped kernel
module, so that btf->data doesn't get freed. Taking the refcount can
happen in the sysfs mmap handler, but dropping it is tricky. kernfs /
sysfs doesn't allow using vm_ops->close (see kernfs_fop_mmap). It
seems possible to use struct kernfs_ops->release(), but I don't
understand at all how that deals with multiple mmaps of the same file
in a single process. Also makes me wonder what happens when a process
mmaps the kmod BTF, the module is unloaded and then the process
attempts to access the mmap. My cursory understanding is that this
would raise a fault, which isn't great at all.

If nobody objects / has solutions I'll send a v3 of my original patch
with reviews addressed but without being able to mmap kmods.

Thanks
Lorenz