From: sashiko-bot@kernel.org
To: "Mark Korenberg" <socketpair@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 2/2] bpftool: Make the LLVM disassembler an optional runtime dependency
Date: Thu, 29 Oct 2026 12:54:21 +0000 [thread overview]
Message-ID: <sashiko-outbox-189325@kernel.org> (raw)
In-Reply-To: <20261029-bpftool-plugin-v2-2-1a47b2391b0b@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpftool: llvm_plugin_find() misses staged plugins and prefers system plugin
--
commit aa662f293876360fc9cf9139e86022f88a5bbb64
Author: Mark Korenberg <socketpair@gmail.com>
bpftool: Make the LLVM disassembler an optional runtime dependency
This commit moves the libLLVM-based JIT disassembler into an optional
shared library plugin (bpftool-llvm.so) loaded on demand via dlopen()
when disassembling JITed programs or checking feature availability.
Link: https://github.com/libbpf/bpftool/issues/262
> diff --git a/tools/bpf/bpftool/jit_disasm.c b/tools/bpf/bpftool/jit_disasm.c
> index 5ff144ce84a1c..2691252a115b9 100644
> --- a/tools/bpf/bpftool/jit_disasm.c
> +++ b/tools/bpf/bpftool/jit_disasm.c
[ ... ]
> @@ -45,7 +45,105 @@ static int oper_count;
[ ... ]
> +/*
> + * Look for the plugin in its install directory, then next to the bpftool
> + * binary so that bpftool also works from its build directory. Do not look
> + * in the current directory: bpftool usually runs as root, and would then
> + * load any library planted in the directory it is run from.
> + */
> +static int llvm_plugin_find(char *path, size_t size)
> +{
> + char exe[PATH_MAX];
> + ssize_t len;
> + char *dir;
> + int n;
> +
> + snprintf(path, size, "%s/%s", LLVM_PLUGIN_DIR, LLVM_PLUGIN_NAME);
> + if (!access(path, F_OK))
> + return 0;
> +
> + len = readlink("/proc/self/exe", exe, sizeof(exe) - 1);
> + if (len < 0)
> + return -1;
> + exe[len] = '\0';
> + dir = strrchr(exe, '/');
> + if (!dir)
> + return -1;
> + *dir = '\0';
> +
> + n = snprintf(path, size, "%s/%s", exe, LLVM_PLUGIN_NAME);
> + if (n < 0 || (size_t)n >= size)
> + return -1;
> + return access(path, F_OK);
> +}
[Severity: Medium]
Can llvm_plugin_find() fail to locate bpftool-llvm.so when bpftool is
installed into a staging directory via DESTDIR, such as in the BPF
selftests build?
In tools/testing/selftests/bpf/Makefile, $(DEFAULT_BPFTOOL) and
$(CROSS_BPFTOOL) are built and staged with:
tools/testing/selftests/bpf/Makefile:
$(Q)$(MAKE) $(submake_extras) -C $(BPFTOOLDIR) \
...
OUTPUT=$(HOST_BUILD_DIR)/bpftool/ \
...
prefix= DESTDIR=$(HOST_SCRATCH_DIR)/ install-bin
Because prefix= is empty and libdir is not overridden, tools/bpf/bpftool/Makefile
sets libdir to /lib and compiles jit_disasm.o with:
tools/bpf/bpftool/Makefile:
prefix ?= /usr/local
libdir ?= $(prefix)/lib
...
CFLAGS += -DLLVM_PLUGIN_DIR='"$(libdir)/bpftool"'
Meanwhile, the install-bin target places the binary and plugin in separate
directories under $(DESTDIR):
tools/bpf/bpftool/Makefile:
install-bin: $(OUTPUT)bpftool $(LLVM_PLUGIN)
$(call QUIET_INSTALL, bpftool)
$(Q)$(INSTALL) -m 0755 -d $(DESTDIR)$(prefix)/sbin
$(Q)$(INSTALL) $(OUTPUT)bpftool $(DESTDIR)$(prefix)/sbin/bpftool
ifneq ($(LLVM_PLUGIN),)
$(call QUIET_INSTALL, bpftool-llvm.so)
$(Q)$(INSTALL) -m 0755 -D -t $(DESTDIR)$(libdir)/bpftool $(LLVM_PLUGIN)
endif
This installs bpftool to $(HOST_SCRATCH_DIR)/sbin/bpftool and the plugin to
$(HOST_SCRATCH_DIR)/lib/bpftool/bpftool-llvm.so. When the staged bpftool
runs, llvm_plugin_find() checks /lib/bpftool/bpftool-llvm.so and
$(HOST_SCRATCH_DIR)/sbin/bpftool-llvm.so, missing the staged plugin in
$(HOST_SCRATCH_DIR)/lib/bpftool/bpftool-llvm.so (causing "bpftool prog dump
jited" to fail and "bpftool version" to omit the llvm feature).
Additionally, because llvm_plugin_find() checks LLVM_PLUGIN_DIR before the
directory of /proc/self/exe, wouldn't running an uninstalled ./bpftool from
its build directory on a host where $(LLVM_PLUGIN_DIR)/bpftool-llvm.so is
already installed load the system plugin instead of ./bpftool-llvm.so next
to the binary (and fail without falling back if the installed plugin has a
different BPFTOOL_LLVM_ABI_VERSION or incompatible sanitizer flags)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-bpftool-plugin-v2-0-1a47b2391b0b@gmail.com?part=2
prev parent reply other threads:[~2026-10-29 12:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 12:43 [PATCH bpf-next v2 0/2] bpftool: Make the LLVM disassembler an optional runtime dependency Mark Korenberg via B4 Relay
2026-10-29 12:43 ` Mark Korenberg
2026-10-29 12:43 ` [PATCH bpf-next v2 1/2] bpftool: Fix disposal of the LLVM disassembler context Mark Korenberg via B4 Relay
2026-10-29 12:43 ` Mark Korenberg
2026-10-29 12:43 ` [PATCH bpf-next v2 2/2] bpftool: Make the LLVM disassembler an optional runtime dependency Mark Korenberg via B4 Relay
2026-10-29 12:43 ` Mark Korenberg
2026-10-29 12:54 ` sashiko-bot [this message]
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=sashiko-outbox-189325@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=socketpair@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.