[GIT PULL] RTLA: Fixes for v7.2

[Steven Rostedt <steven@rostedt.org>]

Linus,

RTLA fixes for v7.2

- Fix timerlat top actions triggering on signal

  Fix a bug in RTLA's timerlat top actions feature where on-threshold
  actions are triggered on any signal, regardless of whether a latency
  spike had actually occurred during the measurement.

  The return retval was checked for non-zero to do actions. But if a
  signal came in, it returns a negative and actions were being
  incorrectly triggered when they should not have been.


Please pull the latest trace-tools-v7.2-rc5 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace-tools-v7.2-rc5

Tag SHA1: faa747ade50ef9b7eb6db4fb64274150c703ffcf
Head SHA1: fafb66e5903c2bcfc7b7e259042a8282f18a6faa


Tomas Glozar (1):
      rtla/timerlat_top: Fix on-threshold actions firing on signal

----
 tools/tracing/rtla/src/timerlat_top.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
---------------------------
commit fafb66e5903c2bcfc7b7e259042a8282f18a6faa
Author: Tomas Glozar <tglozar@redhat.com>
Date:   Mon Jul 13 16:10:47 2026 +0200

    rtla/timerlat_top: Fix on-threshold actions firing on signal
    
    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>
    Reviewed-by: Wander Lairson Costa <wander@redhat.com>
    Link: https://lore.kernel.org/r/20260713141047.687877-1-tglozar@redhat.com
    Signed-off-by: Tomas Glozar <tglozar@redhat.com>

diff --git a/tools/tracing/rtla/src/timerlat_top.c b/tools/tracing/rtla/src/timerlat_top.c
index 18e1071a2e24..6206a0a565ad 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)