From: Kaitao Cheng <kaitao.cheng@linux.dev>
To: Yonghong Song <yonghong.song@linux.dev>
Cc: davemarchevsky@fb.com, bpf@vger.kernel.org, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, memxor@gmail.com, song@kernel.org,
jolsa@kernel.org, linux-kernel@vger.kernel.org,
Kaitao Cheng <chengkaitao@kylinos.cn>
Subject: Re: [PATCH] bpf: Clear rb node linkage when freeing bpf_rb_root
Date: Fri, 5 Jun 2026 17:51:29 +0800 [thread overview]
Message-ID: <85fced77-a911-420c-b74b-443b5be8c87b@linux.dev> (raw)
In-Reply-To: <5e4e8089-6eb7-4eec-8ad2-820d99368a55@linux.dev>
在 2026/6/2 02:06, Yonghong Song 写道:
>
>
> On 5/31/26 10:58 PM, Kaitao Cheng wrote:
>> From: Kaitao Cheng <chengkaitao@kylinos.cn>
>>
>> bpf_rb_root_free() detaches the root by copying the current rb_root_cached
>> and then replacing the live root with RB_ROOT_CACHED. It then walks the
>> copied root and drops each object contained in the tree.
>>
>> This leaves the rb node state intact while dropping the object. If the
>> object is refcounted and survives the drop, its bpf_rb_node_kern still
>> contains an owner pointer to the freed root and stale rb tree linkage. If
>> a later bpf_rb_root allocation reuses the same address, bpf_rbtree_remove()
>> can incorrectly pass the owner check and call rb_erase_cached() on a node
>> whose rb pointers belong to the old tree.
>>
>> Mirror the list draining behavior by marking nodes as busy while the root
>> is being detached, then clear the rb node and release the owner before
>> dropping the containing object. This makes surviving nodes unowned and
>> safe to reject from remove or accept for a later add.
>>
>> Fixes: 9c395c1b99bd ("bpf: Add basic bpf_rb_{root,node} support")
>> Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
>
> Please use [PATCH bpf] tag so CI can test it. Do we need a selftest?
The bug fixed by this patch has fairly strict reproduction conditions,
so it is difficult to find a stable reproducer.
I have addressed the other feedback. Thanks for your review.
please see v2 for details.
https://lore.kernel.org/all/20260605094143.5509-1-kaitao.cheng@linux.dev/
> LGTM with a few nits below.
>
> Acked-by: Yonghong Song <yonghong.song@linux.dev>
>
>> ---
>> kernel/bpf/helpers.c | 18 +++++++++++++-----
>> 1 file changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
>> index 9ca195104667..46e8eada463b 100644
>> --- a/kernel/bpf/helpers.c
>> +++ b/kernel/bpf/helpers.c
>> @@ -2307,22 +2307,30 @@ void bpf_rb_root_free(const struct btf_field *field, void *rb_root,
>> {
>> struct rb_root_cached orig_root, *root = rb_root;
>> struct rb_node *pos, *n;
>> - void *obj;
>> BUILD_BUG_ON(sizeof(struct rb_root_cached) > sizeof(struct bpf_rb_root));
>> BUILD_BUG_ON(__alignof__(struct rb_root_cached) > __alignof__(struct bpf_rb_root));
>> __bpf_spin_lock_irqsave(spin_lock);
>> orig_root = *root;
>> + bpf_rbtree_postorder_for_each_entry_safe(pos, n, &orig_root.rb_root) {
>> + struct bpf_rb_node_kern *node;
>
> Move 'struct bpf_rb_node_kern *node;' and the below to the top function declaration.
> This will make code simpler.
>
>> +
>> + node = rb_entry(pos, struct bpf_rb_node_kern, rb_node);
>> + WRITE_ONCE(node->owner, BPF_PTR_POISON);
>> + }
>> *root = RB_ROOT_CACHED;
>> __bpf_spin_unlock_irqrestore(spin_lock);
>> bpf_rbtree_postorder_for_each_entry_safe(pos, n, &orig_root.rb_root) {
>> - obj = pos;
>> - obj -= field->graph_root.node_offset;
>
> We can keep this two ...
>
>> + struct bpf_rb_node_kern *node;
>> -
>> - __bpf_obj_drop_impl(obj, field->graph_root.value_rec, false);
>> + node = rb_entry(pos, struct bpf_rb_node_kern, rb_node);
>> + RB_CLEAR_NODE(pos);
>> + /* Ensure __bpf_rbtree_add() sees the node as unlinked. */
>> + smp_store_release(&node->owner, NULL);
>> + __bpf_obj_drop_impl((char *)pos - field->graph_root.node_offset,
>> + field->graph_root.value_rec, false);
>
> and then __bpf_obj_drop_impl(...) will not change.
>
>> }
>> }
>>
>
--
Thanks
Kaitao Cheng
prev parent reply other threads:[~2026-06-05 9:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 5:58 [PATCH] bpf: Clear rb node linkage when freeing bpf_rb_root Kaitao Cheng
2026-06-01 6:15 ` sashiko-bot
2026-06-03 8:42 ` Kaitao Cheng
2026-06-01 6:44 ` bot+bpf-ci
2026-06-01 18:06 ` Yonghong Song
2026-06-05 9:51 ` Kaitao Cheng [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=85fced77-a911-420c-b74b-443b5be8c87b@linux.dev \
--to=kaitao.cheng@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chengkaitao@kylinos.cn \
--cc=daniel@iogearbox.net \
--cc=davemarchevsky@fb.com \
--cc=eddyz87@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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.