From: Yonghong Song <yonghong.song@linux.dev>
To: Leon Hwang <leon.hwang@linux.dev>, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, memxor@gmail.com,
ameryhung@gmail.com, linux-kernel@vger.kernel.org,
kernel-patches-bot@fb.com
Subject: Re: [PATCH bpf-next v4 4/4] selftests/bpf: Add tests to verify freeing the special fields when update hash and local storage maps
Date: Tue, 4 Nov 2025 09:30:27 -0800 [thread overview]
Message-ID: <02b8c4ba-eb24-41e2-813c-98b83561ef9d@linux.dev> (raw)
In-Reply-To: <20251030152451.62778-5-leon.hwang@linux.dev>
On 10/30/25 8:24 AM, Leon Hwang wrote:
> Add tests to verify that updating hash and local storage maps decrements
> refcount when BPF_KPTR_REF objects are involved.
>
> The tests perform the following steps:
>
> 1. Call update_elem() to insert an initial value.
> 2. Use bpf_refcount_acquire() to increment the refcount.
> 3. Store the node pointer in the map value.
> 4. Add the node to a linked list.
> 5. Probe-read the refcount and verify it is *2*.
> 6. Call update_elem() again to trigger refcount decrement.
> 7. Probe-read the refcount and verify it is *1*.
>
> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
I applied this patch only (i.e., not including patches 1/2/3) to master
branch and do bpf selftest and all tests succeeded.
[root@arch-fb-vm1 bpf]# ./test_progs -t refcounted_kptr
#294/1 refcounted_kptr/insert_read_both: remove from tree + list:OK
...
#294/18 refcounted_kptr/pcpu_hash_refcount_leak:OK
#294/19 refcounted_kptr/check_pcpu_hash_refcount:OK
#294/20 refcounted_kptr/hash_lock_refcount_leak:OK
#294/21 refcounted_kptr/check_hash_lock_refcount:OK
#294/22 refcounted_kptr/rbtree_sleepable_rcu:OK
#294/23 refcounted_kptr/rbtree_sleepable_rcu_no_explicit_rcu_lock:OK
#294/24 refcounted_kptr/cgroup_storage_lock_refcount_leak:OK
#294/25 refcounted_kptr/check_cgroup_storage_lock_refcount:OK
...
Did I miss anything?
> ---
> .../bpf/prog_tests/refcounted_kptr.c | 134 +++++++++++++++++-
> .../selftests/bpf/progs/refcounted_kptr.c | 129 +++++++++++++++++
> 2 files changed, 262 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/refcounted_kptr.c b/tools/testing/selftests/bpf/prog_tests/refcounted_kptr.c
> index d6bd5e16e6372..0ec91ff914af7 100644
> --- a/tools/testing/selftests/bpf/prog_tests/refcounted_kptr.c
> +++ b/tools/testing/selftests/bpf/prog_tests/refcounted_kptr.c
> @@ -3,7 +3,7 @@
>
> #include <test_progs.h>
> #include <network_helpers.h>
> -
> +#include "cgroup_helpers.h"
> #include "refcounted_kptr.skel.h"
> #include "refcounted_kptr_fail.skel.h"
>
> @@ -44,3 +44,135 @@ void test_refcounted_kptr_wrong_owner(void)
> ASSERT_OK(opts.retval, "rbtree_wrong_owner_remove_fail_a2 retval");
> refcounted_kptr__destroy(skel);
> }
> +
> +static void test_refcnt_leak(struct refcounted_kptr *skel, int key, void *values, size_t values_sz,
> + u64 flags, struct bpf_map *map, struct bpf_program *prog_leak,
> + struct bpf_program *prog_check, struct bpf_test_run_opts *opts)
> +{
> + int ret, fd;
> +
> + ret = bpf_map__update_elem(map, &key, sizeof(key), values, values_sz, flags);
> + if (!ASSERT_OK(ret, "bpf_map__update_elem init"))
> + return;
> +
> + fd = bpf_program__fd(prog_leak);
> + ret = bpf_prog_test_run_opts(fd, opts);
> + if (!ASSERT_OK(ret, "bpf_prog_test_run_opts"))
> + return;
> + if (!ASSERT_EQ(skel->bss->kptr_refcount, 2, "refcount"))
> + return;
> +
> + ret = bpf_map__update_elem(map, &key, sizeof(key), values, values_sz, flags);
> + if (!ASSERT_OK(ret, "bpf_map__update_elem dec refcount"))
> + return;
> +
> + fd = bpf_program__fd(prog_check);
> + ret = bpf_prog_test_run_opts(fd, opts);
> + ASSERT_OK(ret, "bpf_prog_test_run_opts");
> + ASSERT_EQ(skel->bss->kptr_refcount, 1, "refcount");
> +}
> +
[...]
next prev parent reply other threads:[~2025-11-04 17:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-30 15:24 [PATCH bpf-next v4 0/4] bpf: Free special fields when update hash and local storage maps Leon Hwang
2025-10-30 15:24 ` [PATCH bpf-next v4 1/4] bpf: Free special fields when update [lru_,]percpu_hash maps Leon Hwang
2025-10-30 15:24 ` [PATCH bpf-next v4 2/4] bpf: Free special fields when update hash maps with BPF_F_LOCK Leon Hwang
2025-10-30 15:24 ` [PATCH bpf-next v4 3/4] bpf: Free special fields when update local storage " Leon Hwang
2025-10-30 22:35 ` Alexei Starovoitov
2025-11-03 5:17 ` Leon Hwang
2025-11-03 17:24 ` Alexei Starovoitov
2025-10-30 15:24 ` [PATCH bpf-next v4 4/4] selftests/bpf: Add tests to verify freeing the special fields when update hash and local storage maps Leon Hwang
2025-11-04 17:30 ` Yonghong Song [this message]
2025-11-05 2:14 ` Leon Hwang
2025-11-05 3:35 ` Yonghong Song
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=02b8c4ba-eb24-41e2-813c-98b83561ef9d@linux.dev \
--to=yonghong.song@linux.dev \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-patches-bot@fb.com \
--cc=kpsingh@kernel.org \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
/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