Tomas Glozar fafb66e590 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 3138df6f0c ("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: 3138df6f0c ("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>		2026-07-21 15:42:08 +02:00
..
latency	tracing/tools: Fix incorrcet short option in usage text for --threads	2025-11-07 07:59:37 -05:00
rtla	rtla/timerlat_top: Fix on-threshold actions firing on signal	2026-07-21 15:42:08 +02:00
Makefile	tools/tracing: Update Makefile to build rtla	2022-01-27 19:15:47 -05:00