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); + } else { + setup_boot_kprobe_events(); + } return 0; } -- 2.25.1
