Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Using `WARN_ON` inside `event_test_stuff()` causes a massive warning storm and potential soft lockup if kthread creation repeatedly fails. --
--- Patch [1]: [PATCH v2] tracing: Fix crash passing ERR_PTR to kthread_stop() --- commit 692df106ab8d8e56701ad9c14c135871ee02df4a Author: Hui Su <[email protected]> tracing: Fix crash passing ERR_PTR to kthread_stop() This commit adds a check for the return value of kthread_run() in event_test_stuff() to prevent passing an ERR_PTR to kthread_stop() if thread creation fails under memory pressure during boot-time trace self tests. > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c > index 0356cae0cf74e..9e941e5805f5e 100644 > --- a/kernel/trace/trace_events.c > +++ b/kernel/trace/trace_events.c > @@ -3866,6 +3866,8 @@ static __init void event_test_stuff(void) > struct task_struct *test_thread; > > test_thread = kthread_run(event_test_thread, NULL, "test-events"); > + if (WARN_ON(IS_ERR(test_thread))) > + return; [Severity: High] Does this risk causing a console flood and soft lockup if thread creation persistently fails? During boot-time trace self tests, event_test_stuff() is called within large loops spanning all trace events: kernel/trace/trace_events.c:event_trace_self_tests() { ... list_for_each_entry(file, &tr->events, list) { ... ftrace_event_enable_disable(file, 1); event_test_stuff(); ftrace_event_enable_disable(file, 0); ... } If kthread creation fails, WARN_ON prints a full stack trace and returns. Since event_test_stuff() returns void, the caller blindly continues to the next trace event, potentially leading to thousands of consecutive stack dumps. Could this be changed to WARN_ON_ONCE() or modified to abort the test loop gracefully? > msleep(1); > kthread_stop(test_thread); > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
