Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Samuel Wu <wusamuel@google.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Ihor Solodrai <ihor.solodrai@linux.dev>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	Emil Tsalapatis <emil@etsalapatis.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
	llvm@lists.linux.dev
Subject: Re: [PATCH bpf-next v2 4/6] libbpf: Resolve typeless ksyms via KALLSYMS_QUERY ioctl
Date: Thu, 29 Oct 2026 22:33:44 +0000	[thread overview]
Message-ID: <20261029223344.5dbe60d5@pumpkin> (raw)
In-Reply-To: <CAG2Kctra0GYjkzggB0cdMxPK-b9U9x-m+gR6E8goAYvhsNXEdA@mail.gmail.com>

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

> On Wed, Oct 28, 2026 at 7:01 AM David Laight
> <david.laight.linux@gmail.com> wrote:
> >
> > On Tue, 27 Oct 2026 15:07:44 -0700
> > Samuel Wu <wusamuel@google.com> wrote:
> >  
> > > On Mon, Oct 26, 2026 at 2:28 AM Jiri Olsa <olsajiri@gmail.com> 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@mail.gmail.com/
> > >
> > > [...]
> > >  
> >  


  reply	other threads:[~2026-10-29 22:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23  0:16 [PATCH bpf-next v2 0/6] kallsyms: Add KALLSYMS_QUERY ioctl to /proc/kallsyms Samuel Wu
2026-10-23  0:16 ` [PATCH bpf-next v2 1/6] " Samuel Wu
2026-10-23  0:51   ` bot+bpf-ci
2026-10-27 21:31     ` Samuel Wu
2026-10-25 23:29   ` Randy Dunlap
2026-10-27 21:33     ` Samuel Wu
2026-10-27 22:24   ` Andrii Nakryiko
2026-10-29 21:58     ` Samuel Wu
2026-10-29 22:09       ` Andrii Nakryiko
2026-10-29 22:35         ` Samuel Wu
2026-10-29 22:54           ` Andrii Nakryiko
2026-10-30  0:23             ` Samuel Wu
2026-10-28 13:40   ` David Laight
2026-10-29 22:05     ` Samuel Wu
2026-10-29 22:16       ` Andrii Nakryiko
2026-10-30  0:28         ` Samuel Wu
2026-10-23  0:16 ` [PATCH bpf-next v2 2/6] tools: Copy KALLSYMS_QUERY definitions to linux/fs.h Samuel Wu
2026-10-23  0:16 ` [PATCH bpf-next v2 3/6] docs/procfs: Document KALLSYMS_QUERY ioctl on /proc/kallsyms Samuel Wu
2026-10-23  0:16 ` [PATCH bpf-next v2 4/6] libbpf: Resolve typeless ksyms via KALLSYMS_QUERY ioctl Samuel Wu
2026-10-23  0:51   ` bot+bpf-ci
2026-10-27 21:45     ` Samuel Wu
2026-10-26  9:28   ` Jiri Olsa
2026-10-27 22:07     ` Samuel Wu
2026-10-28 14:01       ` David Laight
2026-10-29 21:35         ` Samuel Wu
2026-10-29 22:33           ` David Laight [this message]
2026-10-23  0:16 ` [PATCH bpf-next v2 5/6] selftests/bpf: Test typeless module ksym resolution Samuel Wu
2026-10-23  0:16 ` [PATCH bpf-next v2 6/6] selftests/proc: Add KALLSYMS_QUERY tests Samuel Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261029223344.5dbe60d5@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=jack@suse.cz \
    --cc=justinstitt@google.com \
    --cc=kernel-team@android.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=olsajiri@gmail.com \
    --cc=rdunlap@infradead.org \
    --cc=skhan@linuxfoundation.org \
    --cc=song@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wusamuel@google.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox