linux-kernel - Re: [PATCH 0/5] rtla/timerlat: Stop on signal properly when overloaded

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] [day] [month] [year] [list]

Message-ID: <CAP4=nvTfJzG=zSETao_ukAQUSVrjZeRTw1+OEMg_LNJqdW11jQ@mail.gmail.com>
Date: Fri, 17 Jan 2025 16:55:04 +0100
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>, 
	Gabriele Monaco <gmonaco@...hat.com>
Subject: Re: [PATCH 0/5] rtla/timerlat: Stop on signal properly when overloaded

pá 17. 1. 2025 v 16:29 odesílatel Steven Rostedt <rostedt@...dmis.org> napsal:
> Hmm, the timerlat event could probably get access to a trigger to allow it
> to do the work in the kernel like what the 'hist' triggers do. We can
> extend on that.
>

If we only need to count the numbers, that would be a perfect
solution: use the hist trigger in place of the BPF program (no need to
reinvent the wheel!). I'll have to look at exactly what we need.

> The reason I haven't written a BPF program yet, is because when I feel
> there's a useful operation that can be done, I just extend ftrace to do it
> ;-)

I used to work with BPF, so I usually think of a BPF solution first,
then I think about whether I can replace the BPF part :D

Tomas