From: Mahe Tardy <mahe.tardy@gmail.com>
To: bpf@vger.kernel.org
Cc: Quentin Monnet <qmo@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
Shuah Khan <shuah@kernel.org>, Mahe Tardy <mahe.tardy@gmail.com>,
Tianyi Chen <hi@tychen.cc>, Gyutae Bae <gyutae.bae@navercorp.com>,
Hui Su <sh_def@163.com>, Josef Bacik <josef@toxicpanda.com>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: [PATCH bpf-next v3 1/5] libbpf: Count entry programs for bpf_gen__init()
Date: Mon, 2 Nov 2026 20:13:52 +0000 [thread overview]
Message-ID: <20261102201356.5798-2-mahe.tardy@gmail.com> (raw)
In-Reply-To: <20261102201356.5798-1-mahe.tardy@gmail.com>
Commit '259172bb6514 ("libbpf: Fix gen_loader assumption on number of
programs.")' explicitly mention that we may pass a higher number of
progs because we include subprogs and autoload=false to bpf_gen__init()
generating a bigger cleanup section which is harmless.
This is in preparation for the next commits that will introduce cleanup
of the link_fds to bpf_gen__init(). We don't want to overallocate but
have the correct count of progs in this situation so that the
program-slot count matches the programs exposed by the skeleton.
Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
---
tools/lib/bpf/libbpf.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 02e75b183ed0..a7cbe7204043 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -9800,7 +9800,7 @@ static int bpf_object_load(struct bpf_object *obj, int extra_log_level, const ch
* permit cross-endian creation of "light skeleton".
*/
if (obj->gen_loader) {
- int nr_func_ptr_maps = 0, nr_progs = 0, i;
+ int nr_func_ptr_maps = 0, nr_progs = 0, nr_obj_progs = 0, i;
bool text_has_callx = false;
/*
@@ -9815,13 +9815,16 @@ static int bpf_object_load(struct bpf_object *obj, int extra_log_level, const ch
if (prog_is_subprog(obj, &obj->programs[i]) &&
prog_has_callx(&obj->programs[i]))
text_has_callx = true;
- for (i = 0; i < obj->nr_programs; i++)
+ for (i = 0; i < obj->nr_programs; i++) {
+ if (prog_is_subprog(obj, &obj->programs[i]))
+ continue;
+ nr_obj_progs++;
if (obj->programs[i].load_strategy != BPF_PROG_LOAD_STRATEGY_DISABLED &&
- !prog_is_subprog(obj, &obj->programs[i]) &&
(text_has_callx || prog_has_callx(&obj->programs[i])))
nr_progs++;
+ }
bpf_gen__init(obj->gen_loader, obj->log_level | extra_log_level,
- obj->nr_programs, obj->nr_maps, nr_func_ptr_maps * nr_progs);
+ nr_obj_progs, obj->nr_maps, nr_func_ptr_maps * nr_progs);
} else if (!is_native_endianness(obj)) {
pr_warn("object '%s': loading non-native endianness is unsupported\n", obj->name);
return libbpf_err(-LIBBPF_ERRNO__ENDIAN);
--
2.43.0
next prev parent reply other threads:[~2026-11-02 20:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 20:13 [PATCH bpf-next v3 0/5] libbpf: Support gen loader attach Mahe Tardy
2026-11-02 20:13 ` Mahe Tardy [this message]
2026-11-02 20:45 ` [PATCH bpf-next v3 1/5] libbpf: Count entry programs for bpf_gen__init() bot+bpf-ci
2026-11-02 20:13 ` [PATCH bpf-next v3 2/5] libbpf: Track generated loader link FDs Mahe Tardy
2026-11-02 20:13 ` [PATCH bpf-next v3 3/5] libbpf: Emit BPF_LINK_CREATE calls in generated loaders Mahe Tardy
2026-11-03 17:59 ` Alexei Starovoitov
2026-11-02 20:13 ` [PATCH bpf-next v3 4/5] bpftool: Add attach option for light skeleton generation Mahe Tardy
2026-11-02 20:41 ` sashiko-bot
2026-11-02 20:56 ` bot+bpf-ci
2026-11-02 20:13 ` [PATCH bpf-next v3 5/5] selftests/bpf: Test gen loader attach Mahe Tardy
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=20261102201356.5798-2-mahe.tardy@gmail.com \
--to=mahe.tardy@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=gyutae.bae@navercorp.com \
--cc=hi@tychen.cc \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=qmo@kernel.org \
--cc=sh_def@163.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--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 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.