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/
> > >
> > > [...]
> > >
> >
next prev parent 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
all inboxes | Powered by JetHome®