Re: [PATCH bpf-next v3 8/9] bpf, trace, net: prepare CONFIG_DEBUG_INFO_BTF checks for a tristate
flat view
From: bot+bpf-ci@kernel.org
Date: 2026-09-25 23:23:26
Also in:
bpf, linux-kbuild, lkml, rust-for-linux
quoted hunk ↗ jump to hunk
diff --git a/Makefile b/Makefile index 751a08643bf8..f561516e1735 100644 --- a/Makefile +++ b/Makefile@@ -1208,7 +1208,8 @@ endif # include additional Makefiles when needed include-y := scripts/Makefile.warn include-$(CONFIG_DEBUG_INFO) += scripts/Makefile.debug -include-$(CONFIG_DEBUG_INFO_BTF)+= scripts/Makefile.btf +# CONFIG_DEBUG_INFO_BTF is a tristate; BTF is generated for both y and m +include-$(subst m,y,$(CONFIG_DEBUG_INFO_BTF)) += scripts/Makefile.btf include-$(CONFIG_KASAN) += scripts/Makefile.kasan include-$(CONFIG_KCSAN) += scripts/Makefile.kcsan include-$(CONFIG_KMSAN) += scripts/Makefile.kmsan
[ ... ]
quoted hunk ↗ jump to hunk
diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h index 93011f800d0f..2a0098929771 100644 --- a/include/trace/trace_events.h +++ b/include/trace/trace_events.h@@ -398,7 +398,7 @@ static inline notrace int trace_event_get_offsets_##call( \ #define _TRACE_PERF_INIT(call) #endif /* CONFIG_PERF_EVENTS */ -#if defined(CONFIG_BPF_EVENTS) && defined(CONFIG_DEBUG_INFO_BTF) +#if defined(CONFIG_BPF_EVENTS) && IS_ENABLED(CONFIG_DEBUG_INFO_BTF)
Can this change introduce a deadlock when DEBUG_INFO_BTF=m and the
btf_vmlinux module is not yet loaded?
Before this change, with =m the preprocessor guard was false, so
_TRACE_BTF_IDS_INIT() expanded to nothing and trace_event_class.btf_ids
stayed NULL. With IS_ENABLED() the guard is now true for both =y and =m,
so built-in tracepoint classes initialize .btf_ids and create
events/<sys>/<event>/btf_ids tracefs files.
Reading that file for a built-in event goes through event_btf_ids_read()
in kernel/trace/trace_events.c:
scoped_guard(mutex, &event_mutex) {
...
ids = call->class->btf_ids;
...
btf = btf_get_module_btf(mod); /* mod == NULL for built-in */
btf_get_module_btf(NULL) calls bpf_get_btf_vmlinux(), which in the
IS_MODULE(CONFIG_DEBUG_INFO_BTF) case calls request_module("btf_vmlinux")
when the vmlinux BTF has not been loaded yet.
request_module() waits for modprobe to exit (UMH_WAIT_PROC) while
event_mutex is still held. Meanwhile, modprobe does finit_module() ->
load_module() -> prepare_coming_module(), which calls
trace_module_notify():
mutex_lock(&event_mutex);
mutex_lock(&trace_types_lock);
so the btf_vmlinux module load blocks on event_mutex held by the reader,
and the reader blocks waiting for modprobe.
The reader hangs until SIGKILLed, and every other module load and
event_mutex user (enabling/disabling events, kprobe/uprobe creation, etc.)
is stuck. Trigger: with DEBUG_INFO_BTF=m and btf_vmlinux not yet loaded,
`cat /sys/kernel/tracing/events/sched/sched_switch/btf_ids` (or any
syscall event's btf_ids).
Should the BTF be resolved before taking event_mutex, or should this path
return -ENOENT when the vmlinux BTF is not yet present?
[ ... ]
---
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