All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yichong Chen" <chenyichong@uniontech.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v3 1/2] tools/bpf/bpftool: Reset vmlinux BTF after map commands
Date: Tue, 23 Jun 2026 07:38:03 +0000	[thread overview]
Message-ID: <20260623073804.015511F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <E2D0E58A0333B7F3+20260623072220.1421837-2-chenyichong@uniontech.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Memory leak of btf_vmlinux in cgroup.c subcommands
--

commit 20f01631a8680469e5ce832fb9e313bcd34e8d13
Author: Yichong Chen <chenyichong@uniontech.com>

tools/bpf/bpftool: Reset vmlinux BTF after map commands

get_map_kv_btf() caches the vmlinux BTF object when a map uses
btf_vmlinux_value_type_id. This commit introduces free_btf_vmlinux() to
properly clean up the cached btf_vmlinux pointer when the map command releases
the object, keeping batch mode from reusing a freed BTF object.

> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
> index 71a45d96617ed..6b9649294ca1a 100644
> --- a/tools/bpf/bpftool/map.c
> +++ b/tools/bpf/bpftool/map.c
> @@ -790,6 +790,12 @@ static int maps_have_btf(int *fds, int nb_fds)
>  
>  static struct btf *btf_vmlinux;
>  
> +static void free_btf_vmlinux(void)
> +{
> +	btf__free(btf_vmlinux);
> +	btf_vmlinux = NULL;
> +}

[Severity: High]
This isn't a bug introduced by this patch, but since you are fixing the
btf_vmlinux leak here, could there be a similar memory leak of btf_vmlinux in
tools/bpf/bpftool/cgroup.c?

In do_show_tree_fn() and do_show() in cgroup.c, a new BTF object is allocated
with libbpf_find_kernel_btf() and unconditionally assigned to btf_vmlinux
without freeing the previous instance:

tools/bpf/bpftool/cgroup.c:do_show_tree_fn() {
    ...
    btf_vmlinux = libbpf_find_kernel_btf();
    ...
}

Since do_show_tree_fn() is called for each cgroup during nftw() traversal,
could this repeatedly leak the kernel BTF object (which can be several
megabytes) on each cgroup processed? This seems like it could lead to an
out-of-memory crash when running the "bpftool cgroup tree" command on a system
with a moderate number of cgroups.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623072220.1421837-1-chenyichong@uniontech.com?part=1

  reply	other threads:[~2026-06-23  7:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260623072220.1421837-1-chenyichong@uniontech.com>
2026-06-23  7:22 ` [PATCH v3 1/2] tools/bpf/bpftool: Reset vmlinux BTF after map commands Yichong Chen
2026-06-23  7:38   ` sashiko-bot [this message]
2026-06-23  7:22 ` [PATCH v3 2/2] tools/bpf/bpftool: Reset vmlinux BTF after struct_ops commands Yichong Chen
2026-06-23  7:36   ` sashiko-bot

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=20260623073804.015511F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=chenyichong@uniontech.com \
    --cc=sashiko-reviews@lists.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.