Re: [PATCH bpf-next v8 3/8] bpf: Introduce the bpf_list_del kfunc.

bot+bpf-ci
2026-03-16T12:10:53Z

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index e87b263c5fe6..dac346eb1e2f 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2437,6 +2437,8 @@ static struct bpf_list_node *__bpf_list_del(struct bpf_list_head *head,
> */
> if (unlikely(!h->next))
> INIT_LIST_HEAD(h);
> +
> + /* verifier to guarantee n is a list node rather than the head */
> if (list_empty(h))
> return NULL;

Is this comment accurate for all callers of __bpf_list_del()?

For bpf_list_pop_front() and bpf_list_pop_back(), n is derived
from h->next or h->prev. When the list is empty, h->next == h,
so n is the head itself:

kernel/bpf/helpers.c:bpf_list_pop_front() {
struct list_head *h = (void *)head;
return __bpf_list_del(head, h->next);
^^^^^^^ h when list is empty
}

In that case, the list_empty() check is the runtime defense
against n == h, not the verifier. The verifier type guarantee
only applies to the new bpf_list_del() path where node is a
separate bpf_list_node argument.

Since __bpf_list_del() is shared by all three callers, this
comment could mislead a future reader into thinking the
list_empty() check is redundant, when it is actually essential
for the pop paths.

Would it be better to move this comment into bpf_list_del()
itself, or to qualify it as applying only to the bpf_list_del
path?

[ ... ]

---
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/23141914395