> diff --git a/MAINTAINERS b/MAINTAINERS
> index c9b3dfe2498b..29de8e2fe55d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6576,7 +6576,9 @@ F: mm/memcontrol-v1.h
[ ... ]
> diff --git a/tools/testing/selftests/bpf/prog_tests/memcg_async_reclaim.c
> b/tools/testing/selftests/bpf/prog_tests/memcg_async_reclaim.c
> new file mode 100644
> index 000000000000..bf25967c911c
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/memcg_async_reclaim.c
> @@ -0,0 +1,333 @@
[ ... ]
> +void test_memcg_async_reclaim(void)
> +{
> + u64 cgroup_id, old_max, new_max;
> + int cgroup_fd, ret;
> + struct memcg_async_reclaim *skel;
> + struct bpf_link *link = NULL;
> + char data_file1[] = "/tmp/test_data_1_XXXXXX";
> + char data_file2[] = "/tmp/test_data_2_XXXXXX";
Can skel be dereferenced if it isn't initialized? The skel variable is
declared without initialization to NULL, while link is explicitly
initialized to NULL. If control reaches the cleanup block without
memcg_async_reclaim__open_and_load() succeeding, skel remains
uninitialized:
> +cleanup:
> + bpf_link__destroy(link);
> + memcg_async_reclaim__detach(skel);
> + memcg_async_reclaim__destroy(skel);
The generated detach and destroy helpers will dereference skel through
obj->skeleton. Other tests in prog_tests/ check if (skel) before calling
detach/destroy to handle this case safely.
This was raised by XIAO WU in v6 review
(https://lore.kernel.org/all/[email protected]/) in the
context of memcg_ops hierarchies test, but the same pattern appears in
this new async_reclaim test added in v7.
---
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/26429228214
