linux-kernel - Re: [PATCH 0/8] rtla/timerlat: Support actions on threshold and on end

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAP4=nvRVG9dxUQRQe13Y9Xyw01epNTpgxDmb3wbi_ZXBkAC_DQ@mail.gmail.com>
Date: Mon, 23 Jun 2025 16:15:34 +0200
From: Tomas Glozar <tglozar@...hat.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-trace-kernel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, John Kacur <jkacur@...hat.com>, 
	Luis Goncalves <lgoncalv@...hat.com>, Chang Yin <cyin@...hat.com>, 
	Costa Shulyupin <costa.shul@...hat.com>
Subject: Re: [PATCH 0/8] rtla/timerlat: Support actions on threshold and on end

st 11. 6. 2025 v 16:46 odesílatel Arnaldo Carvalho de Melo
<acme@...nel.org> napsal:
>
> I wouldn't add -A and -N, leaving just the long options, as it documents
> scripts (and we should have autocomplete as well), leaving the one
> letter options for things that are used super frequently, which could be
> these new options, after a while, time will tell :-)
>

Hmm, my reasoning for those is that one might have multiple actions,
and the action argument itself is long, so one would get a very long
command, e.g.:

$ rtla timerlat hist -T 10 --on-threshold shell,command="echo
Threshold" --on-end shell,command="echo Tracing stopped"

for the command from the example below. But it's true that this is an
experimental feature, and I don't even precisely know the direction in
which I'm going (which is to be determined based on the use of this in
practice). So your suggestion makes a lot of sense.

>
> I think having the documentation together with the new options is
> desirable.
>

Right, this is a user facing change. I did the documentation
separately before, but that was for a change in implementation (BPF
sample collection). Also, I did not have the documentation at the time
of sending of the patchset ready yet :) I'll add it to the v2.

>
> so --on-threshold ends up being a list of things to do when the
> threshold is hit?
>

Yes, the list is executed in order. Now when I'm looking at the cover
letter, this is not clear, I'm only talking about the "list" of the
supported actions (which I perhaps should more accurately call "set").

>
> That is an interesting example of cross-tool integration using existing
> mechanisms for detecting special events and asking for hardware tracing
> snapshots, good stuff!
>

Thanks!

> At some point we need to have this signalling to not involve userspace,
> shortcircuiting the snapshot request closer to the event of interest,
> inside the kernel.
>

I have a feature in mind for that. We already use a BPF program to
process the samples [note1], which means that BPF tail call [1] can be
used to implement in-kernel actions next to userspace ones. Those can
be built-in BPF programs, or custom BPF programs supplied by the user.

[1] https://docs.ebpf.io/linux/helper-function/bpf_tail_call
[note1] In BPF mode. However, outside BPF mode, actions are not that
useful in the first place, as they are only executed when rtla wakes
up to process samples, incurring up to 1s latency.

Tomas