* Re: [PATCH bpf-next v3 8/9] bpf, trace, net: prepare CONFIG_DEBUG_INFO_BTF checks for a tristate
[not found] <973216fc6e2c9c225b847f0f82941b5e1e2d49944c2b16ff5cbcdcdf2910e8d6@mail.kernel.org>
@ 2026-10-01 23:53 ` Jay Wang
0 siblings, 0 replies; only message in thread
From: Jay Wang @ 2026-10-01 23:53 UTC (permalink / raw)
To: bot+bpf-ci, bpf, ast, daniel, andrii, eddyz87, memxor
Cc: alan.maguire, martin.lau, yonghong.song, jolsa, nathan, nsc,
linux-kbuild, mcgrof, petr.pavlu, samitolvanen, linux-modules,
ojeda, rust-for-linux, arnd, linux-kernel, abuehaze, doebel,
mpohlack, jay.wang.upstream, martin.lau, mason, ihor.solodrai,
rostedt, mhiramat, linux-trace-kernel
Right, fixed in v4 (patch 5/12, with the other tracefs and bpffs
requests that load the BTF):
https://lore.kernel.org/bpf/20261001225214.12351-1-wanjay@amazon.com/
event_btf_ids_read() now calls bpf_load_btf_vmlinux() before it takes
event_mutex, so the btf_vmlinux module load and its trace notifier run
without it; btf_get_module_btf(NULL) under the mutex then finds the BTF
already parsed. More generally, in v4 the lookups themselves never load
the BTF any more (see the reply to Alexei on 4/9): the probe argument
parser (PROBE_EVENTS_BTF_ARGS) loads it explicitly, holding only
dyn_event_ops_mutex, which loading a module never takes. Tested by
reading events/sched/sched_switch/btf_ids, and by creating kprobe events
with BTF arguments, each as the first BTF user after boot.
Jay
^ permalink raw reply [flat|nested] only message in thread