From: Martin KaFai Lau <martin.lau@linux.dev>
To: bpf@vger.kernel.org
Cc: 'Alexei Starovoitov ' <ast@kernel.org>,
'Andrii Nakryiko ' <andrii@kernel.org>,
'Daniel Borkmann ' <daniel@iogearbox.net>,
netdev@vger.kernel.org, kernel-team@meta.com,
'Amery Hung ' <ameryhung@gmail.com>
Subject: [RFC PATCH bpf-next 05/12] bpf: Allow refcounted bpf_rb_node used in bpf_rbtree_{remove,left,right}
Date: Fri, 18 Apr 2025 15:46:43 -0700 [thread overview]
Message-ID: <20250418224652.105998-6-martin.lau@linux.dev> (raw)
In-Reply-To: <20250418224652.105998-1-martin.lau@linux.dev>
From: Martin KaFai Lau <martin.lau@kernel.org>
The bpf_rbtree_{remove,left,right} requires the root's lock to be held.
They also check the node_internal->owner is still owned by that root
before proceeding, so it is safe to allow refcounted bpf_rb_node
pointer to be used in these kfuncs.
In the later selftest, a networking flow (allocated by bpf_obj_new)
can be added to two different rbtrees. There are cases that the flow
is searched from one rbtree, held the refcount of the flow,
and then removed from the another rbtree:
struct fq_flow {
struct bpf_rb_node fq_node;
struct bpf_rb_node rate_node;
struct bpf_refcount refcount;
unsigned long sk_long;
};
int bpf_fq_enqueue(...)
{
/* ... */
bpf_spin_lock(&root->lock);
while (can_loop) {
/* ... */
if (!p)
break;
gc_f = bpf_rb_entry(p, struct fq_flow, fq_node);
if (gc_f->sk_long == sk_long) {
f = bpf_refcount_acquire(gc_f);
break;
}
/* ... */
}
bpf_spin_unlock(&root->lock);
if (f) {
bpf_spin_lock(&q->lock);
bpf_rbtree_remove(&q->delayed, &f->rate_node);
bpf_spin_unlock(&q->lock);
}
}
bpf_rbtree_{left,right} do not need this change but are relaxed together
with bpf_rbtree_remove instead of adding extra verifier logic
to exclude these kfuncs.
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
---
kernel/bpf/verifier.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 3624de1c6925..3b905331ca0e 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -13229,8 +13229,8 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
return -EINVAL;
}
} else {
- if (!type_is_non_owning_ref(reg->type) || reg->ref_obj_id) {
- verbose(env, "%s can only take non-owning bpf_rb_node pointer\n", func_name);
+ if (!type_is_non_owning_ref(reg->type) && !reg->ref_obj_id) {
+ verbose(env, "%s can only take non-owning or refcounted bpf_rb_node pointer\n", func_name);
return -EINVAL;
}
if (in_rbtree_lock_required_cb(env)) {
--
2.47.1
next prev parent reply other threads:[~2025-04-18 22:47 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 22:46 [RFC PATCH bpf-next 00/12] bpf: A fq example similar to the kernel sch_fq.c implementation Martin KaFai Lau
2025-04-18 22:46 ` [RFC PATCH bpf-next 01/12] bpf: Check KF_bpf_rbtree_add_impl for the "case KF_ARG_PTR_TO_RB_NODE" Martin KaFai Lau
2025-04-22 1:05 ` Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` [RFC PATCH bpf-next 02/12] bpf: Simplify reg0 marking for the rbtree kfuncs that return a bpf_rb_node pointer Martin KaFai Lau
2025-04-22 1:14 ` Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` [RFC PATCH bpf-next 03/12] bpf: Add bpf_rbtree_{root,left,right} kfunc Martin KaFai Lau
2025-04-22 1:43 ` Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` [RFC PATCH bpf-next 04/12] selftests/bpf: Adjust failure message in the rbtree_fail test Martin KaFai Lau
2025-04-22 1:44 ` Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` Martin KaFai Lau [this message]
2025-04-22 2:32 ` [RFC PATCH bpf-next 05/12] bpf: Allow refcounted bpf_rb_node used in bpf_rbtree_{remove,left,right} Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` [RFC PATCH bpf-next 06/12] selftests/bpf: Adjust test that does not allow refcounted node in rbtree_remove Martin KaFai Lau
2025-04-22 2:36 ` Kumar Kartikeya Dwivedi
2025-04-22 2:48 ` Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` [RFC PATCH bpf-next 07/12] selftests/bpf: Add rbtree_search test Martin KaFai Lau
2025-04-22 3:03 ` Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` [RFC PATCH bpf-next 08/12] bpf: Simplify reg0 marking for the list kfuncs that return a bpf_list_node pointer Martin KaFai Lau
2025-04-22 3:05 ` Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` [RFC PATCH bpf-next 09/12] bpf: Add bpf_list_{front,back} kfunc Martin KaFai Lau
2025-04-22 3:07 ` Kumar Kartikeya Dwivedi
2025-04-18 22:46 ` [RFC PATCH bpf-next 10/12] selftests/bpf: Add test for bpf_list_{front,back} Martin KaFai Lau
2025-04-22 3:08 ` Kumar Kartikeya Dwivedi
2025-04-25 23:28 ` Martin KaFai Lau
2025-04-18 22:46 ` [RFC PATCH bpf-next 11/12] bpf: net: Add a qdisc kfunc to set sk_pacing_status Martin KaFai Lau
2025-04-18 22:46 ` [RFC PATCH bpf-next 12/12] selftests/bpf: A bpf fq implementation similar to the kernel sch_fq Martin KaFai Lau
2025-04-25 0:13 ` Alexei Starovoitov
2025-04-25 23:50 ` Martin KaFai Lau
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=20250418224652.105998-6-martin.lau@linux.dev \
--to=martin.lau@linux.dev \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@meta.com \
--cc=netdev@vger.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;
as well as URLs for NNTP newsgroup(s).