linux-kernel - Re: [PATCH v2 9/9] Documentation/rtla: Add actions feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP4=nvQWCWAOefHAqA82-VDb-00_y1-0fPOPBEyETJ2Q1EWEwg@mail.gmail.com>
Date: Tue, 22 Jul 2025 09:03:24 +0200
From: Tomas Glozar <tglozar@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	John Kacur <jkacur@...hat.com>, Luis Goncalves <lgoncalv@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Chang Yin <cyin@...hat.com>, 
	Costa Shulyupin <costa.shul@...hat.com>, Crystal Wood <crwood@...hat.com>, 
	Gabriele Monaco <gmonaco@...hat.com>
Subject: Re: [PATCH v2 9/9] Documentation/rtla: Add actions feature

út 22. 7. 2025 v 0:35 odesílatel Steven Rostedt <rostedt@...dmis.org> napsal:
>
> I'm curious to what is looked for for triggering an action. We can poll on
> events and get woken when they are triggered. It may be possible to add
> even more ways to wake a task waiting for something to happen.
>

Threshold actions are triggered immediately after a sample over the
set threshold is detected by rtla. For BPF mode, this happens almost
right after the sample is processed in the BPF program and the
scheduler gets to waking up rtla following a BPF ringbuffer write.
There is only a short delay (up to tens of microseconds) because the
BPF helper defers the wake-up into irq_work.

For non-BPF mode, rtla periodically pulls samples from tracefs, when
it does that, it also checks whether tracing has been turned off. If
yes, that means there was a threshold overflow, and actions are
triggered. Since the period for that is currently set to 1 second, the
action might be delayed up to one second from the threshold occurring,
That delay might be a problem if you need to collect a lot of data
from a ringbuffer in the action, e.g. global Intel PT data collection
for precise troubleshooting of difficult latencies.

Of course, this is just an implementational limitation of the timerlat
tracer. If timerlat had an event (like osnoise's "sample_threshold")
triggered on threshold overflow and if it is possible to wait on it
even without BPF, rtla could wait on that for both BPF and non-BPF
mode instead of what it is currently doing.

Tomas