[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4Bza9mRvjwXU5gbOmOg_Ns=5OAX7-ybE=_wh79i7dwL=ZEw@mail.gmail.com>
Date: Mon, 14 Jul 2025 15:07:27 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Menglong Dong <menglong8.dong@...il.com>
Cc: alexei.starovoitov@...il.com, rostedt@...dmis.org, jolsa@...nel.org,
bpf@...r.kernel.org, Menglong Dong <dongml2@...natelecom.cn>,
Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 12/18] libbpf: don't free btf if tracing_multi
progs existing
On Thu, Jul 3, 2025 at 5:21 AM Menglong Dong <menglong8.dong@...il.com> wrote:
>
> By default, the kernel btf that we load during loading program will be
> freed after the programs are loaded in bpf_object_load(). However, we
> still need to use these btf for tracing of multi-link during attaching.
> Therefore, we don't free the btfs until the bpf object is closed if any
> bpf programs of the type multi-link tracing exist.
>
> Meanwhile, introduce the new api bpf_object__free_btf() to manually free
> the btfs after attaching.
>
> Signed-off-by: Menglong Dong <dongml2@...natelecom.cn>
> ---
> tools/lib/bpf/libbpf.c | 24 +++++++++++++++++++++++-
> tools/lib/bpf/libbpf.h | 2 ++
> tools/lib/bpf/libbpf.map | 1 +
> 3 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index aee36402f0a3..530c29f2f5fc 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -8583,6 +8583,28 @@ static void bpf_object_post_load_cleanup(struct bpf_object *obj)
> obj->btf_vmlinux = NULL;
> }
>
> +void bpf_object__free_btfs(struct bpf_object *obj)
let's not add this as a new API. We'll keep BTF fds open, if
necessary, but not (yet) give user full control of when those FDs will
be closed, I'm not convinced yet we need that much user control over
this
> +{
> + if (!obj->btf_vmlinux || obj->state != OBJ_LOADED)
> + return;
> +
> + bpf_object_post_load_cleanup(obj);
> +}
> +
> +static void bpf_object_early_free_btf(struct bpf_object *obj)
> +{
> + struct bpf_program *prog;
> +
> + bpf_object__for_each_program(prog, obj) {
> + if (prog->expected_attach_type == BPF_TRACE_FENTRY_MULTI ||
> + prog->expected_attach_type == BPF_TRACE_FEXIT_MULTI ||
> + prog->expected_attach_type == BPF_MODIFY_RETURN_MULTI)
> + return;
> + }
> +
> + bpf_object_post_load_cleanup(obj);
> +}
> +
> static int bpf_object_prepare(struct bpf_object *obj, const char *target_btf_path)
> {
> int err;
> @@ -8654,7 +8676,7 @@ static int bpf_object_load(struct bpf_object *obj, int extra_log_level, const ch
> err = bpf_gen__finish(obj->gen_loader, obj->nr_programs, obj->nr_maps);
> }
>
> - bpf_object_post_load_cleanup(obj);
> + bpf_object_early_free_btf(obj);
> obj->state = OBJ_LOADED; /* doesn't matter if successfully or not */
>
> if (err) {
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index d1cf813a057b..7cc810aa7967 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -323,6 +323,8 @@ LIBBPF_API struct bpf_program *
> bpf_object__find_program_by_name(const struct bpf_object *obj,
> const char *name);
>
> +LIBBPF_API void bpf_object__free_btfs(struct bpf_object *obj);
> +
> LIBBPF_API int
> libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
> enum bpf_attach_type *expected_attach_type);
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index c7fc0bde5648..4a0c993221a5 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -444,4 +444,5 @@ LIBBPF_1.6.0 {
> bpf_program__line_info_cnt;
> btf__add_decl_attr;
> btf__add_type_attr;
> + bpf_object__free_btfs;
> } LIBBPF_1.5.0;
> --
> 2.39.5
>
>
Powered by blists - more mailing lists