Re: [PATCH bpf-next v3 5/9] bpf: defer vmlinux kfunc and struct_ops registrations
flat view
From: bot+bpf-ci@kernel.org
Date: 2026-09-25 23:34:45
Also in:
bpf, linux-kbuild, lkml, rust-for-linux
quoted hunk ↗ jump to hunk
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c index 1dd7f9650ae8..207954b5754a 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c
[ ... ]
quoted hunk ↗ jump to hunk
+#ifdef BTF_MODULE_NOTIFIER +/* + * The queue has its own lock: it is drained under btf_vmlinux_lock, and + * btf_module_mutex must not nest inside that (purge_cand_cache() takes + * cand_cache_mutex under btf_module_mutex, and CO-RE fetches the vmlinux + * BTF under cand_cache_mutex). + */ +static DEFINE_MUTEX(btf_vmlinux_regs_mutex);
Does the lock ordering explanation match the actual code? Looking at
the earlier patch 806240f10744 ("bpf: fetch the vmlinux BTF where
kernel types enter a program"), both CO-RE callers now call
bpf_get_btf_vmlinux() before taking cand_cache_mutex:
kernel/bpf/btf.c:bpf_core_apply() {
/* candidates are kernel types: load the vmlinux BTF, outside the mutex */
if (IS_ERR_OR_NULL(bpf_get_btf_vmlinux())) {
...
mutex_lock(&cand_cache_mutex);
and bpf_core_find_cands() uses only bpf_peek_btf_vmlinux() under the
mutex, which takes no lock. Its comment reads "Callers fetch the
vmlinux BTF before taking cand_cache_mutex."
So the btf_vmlinux_lock -> btf_module_mutex -> cand_cache_mutex ->
btf_vmlinux_lock cycle described here does not exist in this tree.
The separate lock is fine. Could the comment and commit message explain
what actually prevents btf_module_mutex from nesting under
btf_vmlinux_lock, or point to what the next patch adds that would
create that constraint?
---
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/36198628965