On Tue, 27 Jan 2026 09:23:12 +0800 Yaxiong Tian <[email protected]> wrote:
> During kernel boot, the setup_boot_kprobe_events() function causes > significant delays, increasing overall startup time. > > The root cause is a lock contention chain: its child function > enable_boot_kprobe_events() requires the event_mutex, which is > already held by early_event_add_tracer(). early_event_add_tracer() > itself is blocked waiting for the trace_event_sem read-write lock, > which is held for an extended period by trace_event_update_all(). > > To resolve this, we have moved the execution of > setup_boot_kprobe_events() to the trace_init_wq workqueue, allowing > it to run asynchronously. > > Signed-off-by: Yaxiong Tian <[email protected]> > --- > kernel/trace/trace_kprobe.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c > index 9953506370a5..4c6621f02696 100644 > --- a/kernel/trace/trace_kprobe.c > +++ b/kernel/trace/trace_kprobe.c > @@ -2031,6 +2031,13 @@ static __init int init_kprobe_trace_early(void) > } > core_initcall(init_kprobe_trace_early); > > +static struct work_struct kprobe_trace_work __initdata; > + > +static void __init kprobe_trace_works_func(struct work_struct *work) > +{ > + setup_boot_kprobe_events(); > +} > + > /* Make a tracefs interface for controlling probe points */ > static __init int init_kprobe_trace(void) > { > @@ -2048,7 +2055,12 @@ static __init int init_kprobe_trace(void) > trace_create_file("kprobe_profile", TRACE_MODE_READ, > NULL, NULL, &kprobe_profile_ops); > > - setup_boot_kprobe_events(); > + if (trace_init_wq) { > + INIT_WORK(&kprobe_trace_work, kprobe_trace_works_func); > + queue_work(trace_init_wq, &kprobe_trace_work); Hmm, this queue_work is not required if kprobe_boot_events_buf[] is empty. We should check it because most of the time we don't need it. Also, deferring initialization makes it indeterminate when this tracing will begin. For kprobe event use case, I think setup_boot_kprobe_events() should check the kprobe_boot_events_buf is empty at first. But I think Yaxiong use case happens when you are using kprobe events via cmdline, is that correct? I think introducing "async" cmdline option is more preferable. BTW, I found that the kprobe events from kernel cmdline will be made after boot-time tracing from bootconfig. Maybe it should be run this earlier timing too. Thank you, > + } else { > + setup_boot_kprobe_events(); > + } > > return 0; > } > -- > 2.25.1 > -- Masami Hiramatsu (Google) <[email protected]>
