Dump the saved IRQ stack trace regardless of whether the event was THREAD_CONTEXT or THREAD_URET.
In the uret case, the latency presumably had not yet crossed the threshold at IRQ time (or else it would have dumped the stack at thread wakeup time, unless we're racing with a change to the threshold), but it may have at least contributed -- and this is possible with THREAD_CONTEXT as well. In any case, it helps with writing reliable rtla tests if we always get a stack trace on a threshold event. Signed-off-by: Crystal Wood <[email protected]> --- kernel/trace/trace_osnoise.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index a9962d4497e8..bb4d195ec74f 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -2508,9 +2508,12 @@ timerlat_fd_read(struct file *file, char __user *ubuf, size_t count, notify_new_max_latency(diff); tlat->tracing_thread = false; - if (osnoise_data.stop_tracing_total) - if (time_to_us(diff) >= osnoise_data.stop_tracing_total) + if (osnoise_data.stop_tracing_total) { + if (time_to_us(diff) >= osnoise_data.stop_tracing_total) { + timerlat_dump_stack(time_to_us(diff)); osnoise_stop_tracing(); + } + } } else { tlat->tracing_thread = false; tlat->kthread = current; -- 2.48.1
