From: bot+bpf-ci@kernel.org
To: hui.zhu@linux.dev, akpm@linux-foundation.org, hannes@cmpxchg.org,
mhocko@kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, muchun.song@linux.dev, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, shuah@kernel.org,
peterz@infradead.org, ojeda@kernel.org, nathan@kernel.org,
kees@kernel.org, tj@kernel.org, jeffxu@chromium.org,
mkoutny@suse.com, kernel@jfarr.cc, brauner@kernel.org,
rdunlap@infradead.org, brgerst@gmail.com, masahiroy@kernel.org,
davem@davemloft.net, kuba@kernel.org, hawk@kernel.org,
inwardvessel@gmail.com, willemb@google.com,
kerneljasonxing@gmail.com, paul.chaignon@gmail.com,
a.s.protopopov@gmail.com, ameryhung@gmail.com,
chenridong@huaweicloud.com, lance.yang@linux.dev,
jiayuan.chen@linux.dev, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, cgroups@vger.kernel.org, bpf@vger.kernel.org,
netdev@vger.kernel.org, linu@kvack.org,
x-kselftest@vger.kernel.org
Cc: zhuhui@kylinos.cn,geliang@kernel.org,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [RFC PATCH bpf-next v3 09/12] selftests/bpf: Add tests for memcg_bpf_ops
Date: Fri, 23 Jan 2026 09:19:07 +0000 (UTC) [thread overview]
Message-ID: <9ab6aaa78c0dcba8b563eab2807eccb0c24bd14fa02d7417cff4284204de7d2d@mail.kernel.org> (raw)
In-Reply-To: <c44accaaaebfc32be13234f82b501a3852ba3f0f.1769157382.git.zhuhui@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]
> diff --git a/tools/testing/selftests/bpf/prog_tests/memcg_ops.c b/tools/testing/selftests/bpf/prog_tests/memcg_ops.c
> new file mode 100644
> index 000000000000..9a8d16296f2d
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/memcg_ops.c
[ ... ]
> +static void real_test_memcg_ops(int read_times)
> +{
> + int ret;
> + char data_file1[] = "/tmp/test_data_XXXXXX";
> + char data_file2[] = "/tmp/test_data_XXXXXX";
> + char time_file1[] = "/tmp/test_time_XXXXXX";
> + char time_file2[] = "/tmp/test_time_XXXXXX";
> + pid_t pid1, pid2;
> + double time1, time2;
[ ... ]
> + pid1 = fork();
> + if (!ASSERT_GE(pid1, 0, "fork"))
> + goto cleanup;
> + if (pid1 == 0)
> + real_test_memcg_ops_child_work(CG_LOW_DIR,
> + data_file1,
> + time_file1,
> + read_times);
> +
> + pid2 = fork();
> + if (!ASSERT_GE(pid1, 0, "fork"))
^^^^
Should this check pid2 instead of pid1? After assigning pid2 = fork(),
checking pid1 means a failed second fork() would go undetected if the
first fork() succeeded.
> + goto cleanup;
> + if (pid2 == 0)
> + real_test_memcg_ops_child_work(CG_HIGH_DIR,
> + data_file2,
> + time_file2,
> + read_times);
[ ... ]
> +void test_memcg_ops_over_high(void)
> +{
> + int err, map_fd;
> + struct memcg_ops *skel;
^^^^^^^^^^^^^^^
The skel variable is not initialized to NULL here. If setup_cgroup()
fails early and jumps to the out label, memcg_ops__detach(skel) would
be called with an uninitialized pointer.
Also, the cleanup path calls memcg_ops__detach() but never calls
memcg_ops__destroy(). Would this leak the skeleton object and its
associated BPF resources?
> + struct bpf_map *map;
> + size_t bss_sz;
> + struct memcg_ops__bss *bss_data;
> + __u32 key = 0;
> + struct bpf_program *prog = NULL;
> + struct bpf_link *link = NULL, *link2 = NULL;
> + DECLARE_LIBBPF_OPTS(bpf_struct_ops_opts, opts);
> + int high_cgroup_id, low_cgroup_fd = -1;
> +
> + err = setup_cgroup(&high_cgroup_id, &low_cgroup_fd, NULL);
> + if (!ASSERT_OK(err, "setup_cgroup"))
> + goto out;
> +
> + skel = memcg_ops__open_and_load();
[ ... ]
> +out:
> + bpf_link__destroy(link);
> + bpf_link__destroy(link2);
> + memcg_ops__detach(skel);
> + close(low_cgroup_fd);
> + cleanup_cgroup_environment();
> +}
[ ... ]
> +void test_memcg_ops_below_low_over_high(void)
> +{
> + int err, map_fd;
> + struct memcg_ops *skel;
Same issue here - skel is not initialized to NULL.
[ ... ]
> +out:
> + bpf_link__destroy(link);
> + bpf_link__destroy(link_high);
> + bpf_link__destroy(link_low);
> + memcg_ops__detach(skel);
[ ... ]
> +void test_memcg_ops_below_min_over_high(void)
> +{
> + int err, map_fd;
> + struct memcg_ops *skel;
Same issue here as well - skel is not initialized to NULL.
[ ... ]
> +out:
> + bpf_link__destroy(link);
> + bpf_link__destroy(link_high);
> + bpf_link__destroy(link_low);
> + memcg_ops__detach(skel);
> + close(high_cgroup_fd);
> + close(low_cgroup_fd);
> + cleanup_cgroup_environment();
> +}
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21280790825
next prev parent reply other threads:[~2026-01-23 9:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 8:55 [RFC PATCH bpf-next v3 00/12] mm: memcontrol: Add BPF hooks for memory controller Hui Zhu
2026-01-23 8:55 ` [RFC PATCH bpf-next v3 01/12] bpf: move bpf_struct_ops_link into bpf.h Hui Zhu
2026-01-23 8:55 ` [RFC PATCH bpf-next v3 02/12] bpf: initial support for attaching struct ops to cgroups Hui Zhu
2026-01-23 9:19 ` bot+bpf-ci
2026-01-23 8:55 ` [RFC PATCH bpf-next v3 03/12] bpf: mark struct oom_control's memcg field as TRUSTED_OR_NULL Hui Zhu
2026-01-23 8:57 ` [RFC PATCH bpf-next v3 04/12] mm: define mem_cgroup_get_from_ino() outside of CONFIG_SHRINKER_DEBUG Hui Zhu
2026-01-23 8:57 ` [RFC PATCH bpf-next v3 05/12] libbpf: introduce bpf_map__attach_struct_ops_opts() Hui Zhu
2026-01-23 9:19 ` bot+bpf-ci
2026-01-23 8:58 ` [RFC PATCH bpf-next v3 06/12] bpf: Pass flags in bpf_link_create for struct_ops Hui Zhu
2026-01-23 8:58 ` [RFC PATCH bpf-next v3 07/12] libbpf: Support passing user-defined flags " Hui Zhu
2026-01-23 9:00 ` [RFC PATCH bpf-next v3 08/12] mm: memcontrol: Add BPF struct_ops for memory controller Hui Zhu
2026-01-23 9:29 ` bot+bpf-ci
2026-01-23 9:00 ` [RFC PATCH bpf-next v3 09/12] selftests/bpf: Add tests for memcg_bpf_ops Hui Zhu
2026-01-23 9:19 ` bot+bpf-ci [this message]
2026-01-23 20:47 ` JP Kobryn
2026-01-26 1:40 ` hui.zhu
2026-01-23 9:00 ` [RFC PATCH bpf-next v3 10/12] mm/bpf: Add BPF_F_ALLOW_OVERRIDE support " Hui Zhu
2026-01-23 9:29 ` bot+bpf-ci
2026-01-23 9:01 ` [RFC PATCH bpf-next v3 11/12] selftests/bpf: Add test for memcg_bpf_ops hierarchies Hui Zhu
2026-01-23 9:18 ` bot+bpf-ci
2026-01-23 9:01 ` [RFC PATCH bpf-next v3 12/12] samples/bpf: Add memcg priority control example Hui Zhu
2026-01-23 9:18 ` bot+bpf-ci
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=9ab6aaa78c0dcba8b563eab2807eccb0c24bd14fa02d7417cff4284204de7d2d@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=a.s.protopopov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=brgerst@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huaweicloud.com \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=geliang@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=hui.zhu@linux.dev \
--cc=ihor.solodrai@linux.dev \
--cc=inwardvessel@gmail.com \
--cc=jeffxu@chromium.org \
--cc=jiayuan.chen@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kees@kernel.org \
--cc=kernel@jfarr.cc \
--cc=kerneljasonxing@gmail.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=lance.yang@linux.dev \
--cc=linu@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=masahiroy@kernel.org \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=paul.chaignon@gmail.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=sdf@fomichev.me \
--cc=shakeel.butt@linux.dev \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=willemb@google.com \
--cc=x-kselftest@vger.kernel.org \
--cc=yonghong.song@linux.dev \
--cc=zhuhui@kylinos.cn \
/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