Re: [PATCH bpf-next v6 02/17] bpf: Convert bpf_selem_unlink_map to failable
From: bot+bpf-ci@kernel.org
Date: 2026-02-05 07:37:47
Also in:
bpf
quoted hunk ↗ jump to hunk
diff --git a/kernel/bpf/bpf_local_storage.c b/kernel/bpf/bpf_local_storage.c index 91b28f4e3..5f7869078 100644 --- a/kernel/bpf/bpf_local_storage.c +++ b/kernel/bpf/bpf_local_storage.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -347,25 +342,28 @@ void bpf_selem_link_storage_nolock(struct bpf_local_storage *local_storage, hlist_add_head_rcu(&selem->snode, &local_storage->list); } -static void bpf_selem_unlink_map(struct bpf_local_storage_elem *selem) +/* Only called in common paths */ +static int bpf_selem_unlink_map(struct bpf_local_storage_elem *selem) {
The comment says "Only called in common paths", but bpf_selem_unlink_map()
is also called from bpf_local_storage_destroy() which the commit message
explicitly identifies as NOT a common path:
bpf_local_storage_destroy()
bpf_selem_unlink_map(selem); <-- not a "common path"
The commit message states: "Remove the selem_linked_to_map_lockless() check
as an selem in the common paths (not bpf_local_storage_map_free() or
bpf_local_storage_destroy())..."
Should this comment be removed or rephrased? I note that later in the series
(commit 6327eea8e) bpf_local_storage_destroy() is rewritten to no longer call
bpf_selem_unlink_map() directly, making the comment accurate at that point.
---
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/21702523104
AI-authorship-score: low
AI-authorship-explanation: The commit demonstrates deep kernel subsystem knowledge, proper coding conventions, and detailed understanding of locking requirements typical of experienced kernel developers.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: Minor documentation issue where a comment incorrectly describes the function's callers; the code itself is functionally correct and the comment becomes accurate later in the patch series.