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 <afazekas@redhat.com>
Signed-off-by: Tomas Glozar <tglozar@redhat.com>
---
 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

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 <afazekas@redhat.com>
> Signed-off-by: Tomas Glozar <tglozar@redhat.com>
> ---
>  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 <wander@redhat.com>