From: bot+bpf-ci@kernel.org
To: pilgrimtao@gmail.com,martin.lau@linux.dev,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,song@kernel.org,yonghong.song@linux.dev,john.fastabend@gmail.com,kpsingh@kernel.org,sdf@fomichev.me,haoluo@google.com,jolsa@kernel.org,shuah@kernel.org,chengkaitao@kylinos.cn,linux-kselftest@vger.kernel.org
Cc: bpf@vger.kernel.org,linux-kernel@vger.kernel.org,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [PATCH v4 3/6] bpf: add bpf_list_add_impl to insert node after a given list node
Date: Tue, 3 Mar 2026 14:40:29 +0000 (UTC) [thread overview]
Message-ID: <198ab979488effe54f31ecfb8343e154e65f77f5e419fcdabb93be4f0e48b6f4@mail.kernel.org> (raw)
In-Reply-To: <20260303135219.33726-4-pilgrimtao@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]
> Returns 0 on success, -EINVAL if 'prev' is not in a list or 'new'
> is already in a list (or duplicate insertion). On failure, the
> kernel drops the passed-in node.
The commit message says the kernel drops the passed-in node on
failure, but looking at the implementation, only the cmpxchg
failure path actually drops the node:
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
>
> @@ -2497,6 +2497,32 @@
>
> +__bpf_kfunc int bpf_list_add_impl(struct bpf_list_head *head,
> + struct bpf_list_node *new,
> + struct bpf_list_node *prev,
> + void *meta__ign, u64 off)
> +{
> + struct bpf_list_node_kern *kn = (void *)new, *kp = (void *)prev;
> + struct btf_struct_meta *meta = meta__ign;
> + struct list_head *n = &kn->list_head, *p = &kp->list_head;
> +
> + if (unlikely(!head))
> + return -EINVAL;
> +
> + if (WARN_ON_ONCE(READ_ONCE(kp->owner) != head))
> + return -EINVAL;
These two return paths don't drop 'new' before returning. The
verifier unconditionally releases the BPF program's reference to
the new node via ref_convert_owning_non_owning() followed by
release_reference(), so nobody holds a reference to it after this
kfunc returns.
In contrast, __bpf_list_add() always either inserts the node or
drops it via __bpf_obj_drop_impl():
static int __bpf_list_add(...) {
if (cmpxchg(&node->owner, NULL, BPF_PTR_POISON)) {
__bpf_obj_drop_impl((void *)n - off, rec, false);
return -EINVAL;
}
tail ? list_add_tail(n, h) : list_add(n, h);
...
}
These early return paths should be unreachable because the
verifier guarantees head is valid and the lock is held, but
should the commit message be corrected to match the actual
behavior, or should the early error paths also drop the node
for consistency with __bpf_list_add()?
> +
> + if (cmpxchg(&kn->owner, NULL, BPF_PTR_POISON)) {
> + __bpf_obj_drop_impl((void *)n - off,
> + meta ? meta->record : NULL, false);
> + return -EINVAL;
> + }
> +
> + list_add(n, p);
> + WRITE_ONCE(kn->owner, head);
> + return 0;
> +}
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22626485740
next prev parent reply other threads:[~2026-03-03 14:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 13:52 [PATCH v4 0/6] bpf: Extend the bpf_list family of APIs Chengkaitao
2026-03-03 13:52 ` [PATCH v4 1/6] bpf: Introduce the bpf_list_del kfunc Chengkaitao
2026-03-04 3:27 ` Leon Hwang
2026-03-03 13:52 ` [PATCH v4 2/6] selftests/bpf: Add test cases for bpf_list_del Chengkaitao
2026-03-04 3:27 ` Leon Hwang
2026-03-03 13:52 ` [PATCH v4 3/6] bpf: add bpf_list_add_impl to insert node after a given list node Chengkaitao
2026-03-03 14:40 ` bot+bpf-ci [this message]
2026-03-04 3:29 ` Leon Hwang
2026-03-03 13:52 ` [PATCH v4 4/6] selftests/bpf: Add test case for bpf_list_add_impl Chengkaitao
2026-03-03 13:52 ` [PATCH v4 5/6] bpf: add bpf_list_is_first/last/empty kfuncs Chengkaitao
2026-03-04 3:30 ` Leon Hwang
2026-03-03 13:52 ` [PATCH v4 6/6] selftests/bpf: Add test cases for bpf_list_is_first/is_last/empty Chengkaitao
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=198ab979488effe54f31ecfb8343e154e65f77f5e419fcdabb93be4f0e48b6f4@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chengkaitao@kylinos.cn \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=pilgrimtao@gmail.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®