[PATCH] tracing: skip boot kprobe setup when no events were requested

[PATCH] tracing: skip boot kprobe setup when no events were requested

[Wenwen Fu]

setup_boot_kprobe_events() calls enable_boot_kprobe_events() even when
the kprobe_event= boot parameter was not supplied. That call takes
event_mutex without any command-line probes to enable.

Asynchronous eval-map updates also hold event_mutex. A normal boot can
therefore wait in init_kprobe_trace() for this background work despite
having no boot probes to set up.

Return early when the boot-event buffer is empty. Keep the mutex
protection in trace_event_update_all() and retain setup for explicit
kprobe_event= parameters. Bootconfig handles its own probe enablement,
and the existing trace_eval_sync() still waits for background work
before init memory is freed.

Signed-off-by: Wenwen Fu <wenwfu@qti.qualcomm.com>
---
 kernel/trace/trace_kprobe.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index ee8171b19bee..52ec16d8d838 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1995,6 +1995,9 @@ static __init void setup_boot_kprobe_events(void)
 	char *p, *cmd = kprobe_boot_events_buf;
 	int ret;
 
+	if (!kprobe_boot_events_buf[0])
+		return;
+
 	strreplace(kprobe_boot_events_buf, ',', ' ');
 
 	while (cmd && *cmd != '\0') {

Re: [PATCH] tracing: skip boot kprobe setup when no events were requested

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] tracing: redundant unreachable check in setup_boot_kprobe_events()
--

commit 2a160557ebac2d0dc5d93db740f4d45dcc8bd5e9
Author: Wenwen Fu <wenwfu@qti.qualcomm.com>

tracing: skip boot kprobe setup when no events were requested

This commit adds an early return to setup_boot_kprobe_events() when
kprobe_boot_events_buf is empty to avoid acquiring event_mutex in
enable_boot_kprobe_events() when no boot kprobe events were requested.

> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index e41a7c113646b..6e0fff6b4d91f 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -2017,6 +2017,9 @@ static __init void setup_boot_kprobe_events(void)
>  	char *p, *cmd = kprobe_boot_events_buf;
>  	int ret;
>  
> +	if (!kprobe_boot_events_buf[0])
> +		return;

[Severity: Medium]
Can this branch in setup_boot_kprobe_events() ever be reached?

In kernel/trace/trace_kprobe.c, init_kprobe_trace() is the sole caller of
setup_boot_kprobe_events(), and it already returns early when
kprobe_boot_events_buf[0] is NUL:

static __init int init_kprobe_trace(void)
{
	...
	/* If no 'kprobe_event=' cmd is provided, return directly. */
	if (kprobe_boot_events_buf[0] == '\0')
		return 0;

	setup_boot_kprobe_events();

	return 0;
}

Furthermore, enable_boot_kprobe_events() also already checks
trace_kprobe_list_empty() before acquiring event_mutex:

static __init void enable_boot_kprobe_events(void)
{
	...
	if (trace_kprobe_list_empty())
		return;

	guard(mutex)(&event_mutex);
	...
}

Was the check in init_kprobe_trace() meant to be moved into
setup_boot_kprobe_events(), or is this patch redundant with existing checks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106021457.2648231-1-wenwfu@qti.qualcomm.com?part=1