From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a3-smtp.messagingengine.com (fhigh-a3-smtp.messagingengine.com [103.168.172.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09D8F1A682A for ; Fri, 31 Jul 2026 20:03:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.154 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785528230; cv=none; b=twS09JJNdoJ4F/Bw/u7+7vkwaG5j+YYPbkmPeWtUUh4IPRVwYsyebFxNUt7IR0RXkz7yhcKz8Dra2GTjySAmBrzDIju/w65yl9E9cV43/jw5d7j5ROD049vM2ItXtgII6asX1CCThC2OZtEjBPo0DiabGKE+3IM9Hc8RWEBoB1w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785528230; c=relaxed/simple; bh=6uxsXNex0PoQX/Q6RSdFwVrSuLREV9ttu2LaJnD0p5U=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=sPYR4KRDBe7VOJng2vQxIoMNyeN/TysSzvzXofBmBljlvm7s1/UBEM0E0f1+7SOE7MH5g7PXXf1oHfHrhXbJrD5j5XilWt4uqCPPGuIdmJ5F+kauhYhWTG3erP0WrKQafQ0ti7sXwdvvkpZBC/YmthZ785/rVF1kMYrN5as1jbw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rostedt.org; spf=pass smtp.mailfrom=rostedt.org; dkim=pass (2048-bit key) header.d=rostedt.org header.i=@rostedt.org header.b=YbJ4CUyi; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=IO97IxvL; arc=none smtp.client-ip=103.168.172.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rostedt.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rostedt.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rostedt.org header.i=@rostedt.org header.b="YbJ4CUyi"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="IO97IxvL" Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id F05E2140001A; Fri, 31 Jul 2026 16:03:46 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Fri, 31 Jul 2026 16:03:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rostedt.org; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm1; t=1785528226; x=1785614626; bh=qF uyTbWrc8SI6DdU3bpQo4/Zj1c0L/JbdLvoiC+XXm8=; b=YbJ4CUyiQ+tpBCCt3f +CEkKNMaXfhJygtE2BUOzxVicEY0VKUHs/1hhX8/O/aZUpQZatBCkjj6RJVQpCHs EUBiCNJ6QbXwA9LroKTps5BmnzCEm4uX4Yz97MVlkwzjSlSSwnW0BzhnFthezgWk PuyhKP/JE6ehdDm181q2OLqEcBCH+OFrZdab/BPP0DxEfIrIz8lxT/EYILcRBFr/ ayfejj4sUt4nRfk643VpDCyujXIM7uTKnqlrXIISZLCM4MzsaVeaJWvl37gre5iX s0zONlHrGkikkMXW7tgYDEPHaYQ2vDzCVtE/0HeLsW1inkAdX3diov9WwwtSjM7r pLzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1785528226; x=1785614626; bh=qFuyTbWrc8SI6DdU3bpQo4/Zj1c0 L/JbdLvoiC+XXm8=; b=IO97IxvLGJfh/mMRHDNz4DQwoQNVvkEm57NYXBL7LG0+ mEk04pFye99c0D7zC2eB23W+gNNkK5tl/uacu4ZvCftUKdVdwSLmW3Hj0K0/e3sj DfSRrpnbhaaWraYdCnvtyAmMqEbdt6NZePF7zr4fziK3sUsT00zLrNlhYxuXayHb 3/bYzsBCulowRjg9fuaOVnBTsprSJv62tWKbvbswTJ5ocspYTCXWepkWa8O9eMY/ mZs2G5Z0Hnb0SBIjfwc4eshkCklUURmQmraxXiOzfk/1ZXaaCqSjbE9PBBcOEFk7 pUerZd85RXiqEj4r8d6Fy+nqutPhSyA0JmmD6vwQgw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGCxR1it5djQ2ZosqRuRFeL3YFufGcNGiePsBrznAOtnBklXQ5dAp2E3goisGaMkU dPipPl3bOnqXj15k1uYW39DNCotolUbIinRDxVxW8I1LWcO4kedLFi4I6peuS45tsqDE1p m6TXLOcHkQrgRYraoKuo71HlWgVWL4zVCKritIJouDps3DXVSrE/shtg7e9MwlCi+zBTEr X2V3LjBzNtu1UkrhoMYUgYQhEv4D9LpbM9L0N0mGnrG+h1bd+1+TQDt/Azf6GtElIR91SF WfPFtb+RjEtI9a/fN3LL4yLqWxyP9VU+gsiRN2m/DH9vpDF8dH8fiMvmEpYtWgMeEbKgqa Kcmfomovv2nKskuQqDpk+xNjF0MUhhVBqEveveo574aNxtoLRoHz3engtAW4Bbr/AWyoHe Wg35NmsHqoc3sL8KRZ/Ujo+MPen/w7Mnbow73+Y1iyvcDDy9VTY2PqmRjnAb7aMjG6uozf pxRhbAvEiNm0KNNZ2h/whV/jP9BzQ9NDGB1bEv5xNlK5TVnywYBiaK2wZaHSf1rHzy4/2H m0m5sx1N9GkWKkS+fnQFAaehTj2Rr72cHOj8wdxPKgaHbvfLWM+koNISbsVYgBqko0EBXT WtUd7rLzBudBuk26P5o1EfZxtf2k1PeSnA9TqPjbGtO5Zeo8KYx4WltiXyRA X-ME-Proxy: Feedback-ID: id06e481b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 31 Jul 2026 16:03:46 -0400 (EDT) Date: Fri, 31 Jul 2026 16:03:44 -0400 From: Steven Rostedt To: Linus Torvalds Cc: LKML , Tomas Glozar Subject: [GIT PULL] RTLA: Fixes for v7.2 Message-ID: <20260731160344.7a508b97@robin> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 Reviewed-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260713141047.687877-1-tglozar@redhat.com Signed-off-by: Tomas Glozar 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)