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

[David Laight]

On Thu, 29 Oct 2026 14:35:36 -0700
Samuel Wu <wusamuel@xxxxxxxxxx> wrote:

> On Wed, Oct 28, 2026 at 7:01 AM David Laight
> <david.laight.linux@xxxxxxxxx> wrote:
> >
> > On Tue, 27 Oct 2026 15:07:44 -0700
> > Samuel Wu <wusamuel@xxxxxxxxxx> wrote:
> >  
> > > 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.  
> >
> > Isn't that code also O(n*log(m)) ?  
> 
> Yes, sorry maybe I wasn't clear before, but the current code is
> O(n*log(m)), and the ioctl approach would be better since it's m
> lookups of O(log(n)) for vmlinux symbols, where n >> m. However, this
> is a red herring because that path only runs on pre-6.5 kernels, which
> won't have this ioctl.

I was thinking of the ftrace_lookup_symbols() code (called from
bbf_kprobe_multi_link_attach) which O(n*log(m)) (the wrong way around).

David

> 
> > I've got a patch (I might send it after the merge window) that changes
> > one of the ftrace functions to look up every symbol by name, not just
> > when only asked to look up one.
> > It can also use the 'callback' function to detect duplicates.
> > That should be massively faster - especially with my ~18 fold improvement
> > (also waiting for the merge window to end before posting a new
> > (not much changed) version).  
> 
> Excellent, I'll keep an eye out for it!
> 
> > Does look the the code could do with getting the 'symbol name table index'
> > for the symbol so that it can read the entries sequentially from that
> > point onwards.
> >
> > David
> >  
> > >
> > > 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/
> > >
> > > [...]
> > >  
> >