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 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.