Re: [PATCH bpf-next v3 8/9] bpf, trace, net: prepare CONFIG_DEBUG_INFO_BTF checks for a tristate

[bot+bpf-ci@kernel.org]

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

> 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

[ ... ]

> 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