Re: [PATCH bpf-next v2 4/6] libbpf: Resolve typeless ksyms via KALLSYMS_QUERY ioctl

[Samuel Wu]

On Mon, Oct 26, 2026 at 2:28 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
>
> On Thu, Oct 22, 2026 at 05:16:05PM -0700, Samuel Wu wrote:
>
> SNIP
>
> > +static int bpf_object__query_ksyms(struct bpf_object *obj)
> > +{
> > +     struct kallsyms_query q;
> > +     struct extern_desc *ext;
> > +     int err = 0;
> > +     int fd;
> > +     int i;
> > +
> > +     fd = open("/proc/kallsyms", O_RDONLY | O_CLOEXEC);
> > +     if (fd < 0)
> > +             return -errno;
> > +
> > +     for (i = 0; i < obj->nr_extern; i++) {
> > +             ext = &obj->externs[i];
> > +             if (ext->type != EXT_KSYM || ext->ksym.type_id)
> > +                     continue;
> > +
> > +             q = (struct kallsyms_query){
> > +                     .size = sizeof(q),
> > +                     .query_flags = KALLSYMS_QUERY_BY_SYMBOL,
> > +                     .sym_name_addr = ptr_to_u64(ext->name),
> > +             };
> > +
> > +                     err = -errno;
> > +                     if (err == -ENOENT) {
> > +                             err = 0;
> > +                             continue;
> > +                     }
> > +                     if (err == -EADDRNOTAVAIL)
> > +                             pr_warn("extern (ksym) '%s': resolution is ambiguous\n",
> > +                                     ext->name);
> > +                     break;
> > +             }
> > +             ext->is_set = true;
> > +             ext->ksym.addr = q.sym_addr;
> > +             pr_debug("extern (ksym) '%s': resolved in kernel to 0x%llx\n",
> > +                      ext->name, ext->ksym.addr);
> > +     }
> > +     close(fd);
> > +     return err;
> > +}
> > +
> > +static int bpf_object__resolve_typeless_ksyms(struct bpf_object *obj)
> >  {
> > +     int err;
> > +
> > +     err = bpf_object__query_ksyms(obj);
>
> hi,
> we could also add similar support for libbpf_available_kallsyms_parse and
> probably in some other places like bpf_get_ksyms.. which makes me think it
> could be useful to have KALLSYMS_QUERY support for multiple symbols
>
> thanks,
> jirka
>

Thanks for lookiing over this Jiri!

Using KALLSYMS_QUERY for libbpf_available_kallsyms_parse() would
theoretically by O(m*log(n)) instead of O(n*log(m)), where m is the
number of tracefs symbols, and n is lines in kallsyms, with n >> m.
But AFAICT, libbpf_available_kallsyms_parse() would only be called in
pre-6.5 kernels, for kernels without commit 83f74441 (ftrace: Show all
functions with addresses in available_filter_functions_addrs); so this
ioctl could never be called.

And regarding bpf_get_ksyms(), it loads all traceable functions and
needs the full syms table, so a /proc/kallsyms should fits better.

I did profile a slightly different form of querying multiple symbols
at once [1], but didn't see much benefit. struct kallsyms_query is
extensible via size and query_flags, so we can update in the future as
needed.

[1]: https://lore.kernel.org/all/CAG2KctozPSev+EXSpHitM3JWfjufQaEjsPJHS_1HJ1wSm7sJ1w@xxxxxxxxxxxxxx/

[...]