Re: [PATCH bpf-next v3 5/9] bpf: defer vmlinux kfunc and struct_ops registrations

[bot+bpf-ci@kernel.org]

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

> 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

[ ... ]

> +#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