On Mon, Jul 13, 2026 at 04:10:47PM +0200, Tomas Glozar wrote:
> A bug was reported when rtla-timerlat-top tool performs on-threshold
> actions, even though no threshold was hit. This is reproduced even if no
> threshold is set at all:
>
> $ rtla timerlat top -q -c 0 --on-threshold shell,command='echo BAD'
> BAD
> Timer Latency
> ...
>
> The bug is due to incorrect logic in timerlat_top_bpf_main_loop().
> The loop uses timerlat_bpf_wait(), the return values of which are:
>
> - > 0 (number of ringbuffer entries): at least 1 CPU hit threshold
> - = 0: time out
> - < 0: wait was interrupted by a signal
>
> Commit 3138df6f0cd0 ("rtla/timerlat: Exit top main loop on any non-zero
> wait_retval") changed the condition for "threshold hit" from
> "wait_reval == 1" (exactly 1 CPU hit threshold) to "wait_retval != 0",
> to fix a race where multiple CPUs hit the threshold at the same time.
>
> That also made it incorrectly include a signal (< 0), coming from either
> duration expired (SIGALRM) or user interrupt (SIGINT).
>
> Check for wait_retval greater than zero in the if condition to cover all
> return values correctly.
>
> Fixes: 3138df6f0cd0 ("rtla/timerlat: Exit top main loop on any non-zero
> wait_retval")
> Reported-by: Attila Fazekas <[email protected]>
> Signed-off-by: Tomas Glozar <[email protected]>
> ---
> tools/tracing/rtla/src/timerlat_top.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/tracing/rtla/src/timerlat_top.c
> b/tools/tracing/rtla/src/timerlat_top.c
> index 18e1071a2e242..6206a0a565ad3 100644
> --- a/tools/tracing/rtla/src/timerlat_top.c
> +++ b/tools/tracing/rtla/src/timerlat_top.c
> @@ -536,7 +536,7 @@ timerlat_top_bpf_main_loop(struct osnoise_tool *tool)
> if (!params->quiet)
> timerlat_print_stats(tool);
>
> - if (wait_retval != 0) {
> + if (wait_retval > 0) {
> /* Stopping requested by tracer */
> retval = common_threshold_handler(tool);
> if (retval)
> --
> 2.55.0
>
Reviewed-by: Wander Lairson Costa <[email protected]>
