public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 19:35:46 -0800	[thread overview]
Message-ID: <a22dd9a4-94a7-4a9b-ac66-4076caacc9a9@linux.dev> (raw)
In-Reply-To: <697dc64e-8707-44ba-8cda-ba48747f2973@linux.dev>



On 11/4/25 6:14 PM, Leon Hwang wrote:
>
> On 5/11/25 01:30, Yonghong Song wrote:
>>
>> 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?
>>
> Oops.
>
> You should run:
> ./test_progs -t kptr_refcount
>
> The results are as follows:
>
> test_percpu_hash_refcount_leak:PASS:libbpf_num_possible_cpus 0 nsec
> test_percpu_hash_refcount_leak:PASS:calloc values 0 nsec
> test_percpu_hash_refcount_leak:PASS:refcounted_kptr__open_and_load 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem init 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:PASS:refcount 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem dec refcount 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:FAIL:refcount unexpected refcount: actual 2 != expected 1
> #158/1   kptr_refcount_leak/percpu_hash_refcount_leak:FAIL
> test_hash_lock_refcount_leak:PASS:refcounted_kptr__open_and_load 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem init 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:PASS:refcount 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem dec refcount 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:FAIL:refcount unexpected refcount: actual 2 != expected 1
> #158/2   kptr_refcount_leak/hash_lock_refcount_leak:FAIL
> test_cgroup_storage_lock_refcount_leak:PASS:setup_cgroup_environment 0 nsec
> test_cgroup_storage_lock_refcount_leak:PASS:get_root_cgroup 0 nsec
> test_cgroup_storage_lock_refcount_leak:PASS:refcounted_kptr__open_and_load
> 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem init 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:PASS:refcount 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem dec refcount 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:FAIL:refcount unexpected refcount: actual 2 != expected 1
> #158/3   kptr_refcount_leak/cgroup_storage_lock_refcount_leak:FAIL
> #158     kptr_refcount_leak:FAIL
>
> All error logs:
> test_percpu_hash_refcount_leak:PASS:libbpf_num_possible_cpus 0 nsec
> test_percpu_hash_refcount_leak:PASS:calloc values 0 nsec
> test_percpu_hash_refcount_leak:PASS:refcounted_kptr__open_and_load 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem init 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:PASS:refcount 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem dec refcount 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:FAIL:refcount unexpected refcount: actual 2 != expected 1
> #158/1   kptr_refcount_leak/percpu_hash_refcount_leak:FAIL
> test_hash_lock_refcount_leak:PASS:refcounted_kptr__open_and_load 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem init 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:PASS:refcount 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem dec refcount 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:FAIL:refcount unexpected refcount: actual 2 != expected 1
> #158/2   kptr_refcount_leak/hash_lock_refcount_leak:FAIL
> test_cgroup_storage_lock_refcount_leak:PASS:setup_cgroup_environment 0 nsec
> test_cgroup_storage_lock_refcount_leak:PASS:get_root_cgroup 0 nsec
> test_cgroup_storage_lock_refcount_leak:PASS:refcounted_kptr__open_and_load
> 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem init 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:PASS:refcount 0 nsec
> test_refcnt_leak:PASS:bpf_map__update_elem dec refcount 0 nsec
> test_refcnt_leak:PASS:bpf_prog_test_run_opts 0 nsec
> test_refcnt_leak:FAIL:refcount unexpected refcount: actual 2 != expected 1
> #158/3   kptr_refcount_leak/cgroup_storage_lock_refcount_leak:FAIL
> #158     kptr_refcount_leak:FAIL
> Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED
>
> All three tests failed because the refcount remained 2 instead of
> decreasing to 1 after the second update_elem() call.
>
> The CI result [1] also demonstrates this issue.
>
> Sorry for the misleading test name earlier.

Sorry. It is my fault. Indeed, with patches 1-3, the tests indeed failed.
I obviously looked at the wrong selftest.

>
> Links:
> [1] https://github.com/kernel-patches/bpf/pull/10203
>
> Thanks,
> Leon
>
> [...]
>


      reply	other threads:[~2025-11-05  3:35 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
2025-11-05  2:14     ` Leon Hwang
2025-11-05  3:35       ` Yonghong Song [this message]

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=a22dd9a4-94a7-4a9b-ac66-4076caacc9a9@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