linux-kernel - Re: [External] Re: [RFC 00/12] perf record: Add event action support

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: <ff9bc82e-669b-44b7-a02c-f5c704c0cd9b@bytedance.com>
Date: Wed, 4 Dec 2024 16:35:21 +0800
From: Yang Jihong <yangjihong@...edance.com>
To: Namhyung Kim <namhyung@...nel.org>,
 Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: peterz@...radead.org, mingo@...hat.com, mark.rutland@....com,
 alexander.shishkin@...ux.intel.com, jolsa@...nel.org, irogers@...gle.com,
 adrian.hunter@...el.com, kan.liang@...ux.intel.com, james.clark@....com,
 linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [RFC 00/12] perf record: Add event action support

Hello,

On 12/3/24 05:46, Namhyung Kim wrote:
> Hello,
> 
> On Thu, Nov 28, 2024 at 05:14:53PM -0300, Arnaldo Carvalho de Melo wrote:
>> On Thu, Nov 28, 2024 at 09:35:41PM +0800, Yang Jihong wrote:
>>> In perf-record, when an event is triggered, default behavior is to
>>> save sample data to perf.data. Sometimes, we may just want to do
>>> some lightweight actions, such as printing a log.
>>
>>> Based on this requirement, add the --action option to the event to
>>> specify the behavior when the event occurs.
>>
>> 'perf record' is centered on saving data to disk without processing
>> events, while it has sideband events for some needs, like processing BPF
>> related events (PERF_RECORD_BPF_EVENT to catch PERF_BPF_EVENT_PROG_LOAD
>> and UNLOAD), doing things in a "live" way as your patchkit does seems
>> more appropriate to do in 'perf trace' :-)
> 
> Agreed, 'perf trace' looks like a better place as you seem to target
> tracepoint events mostly.
> 
Okay, will do it in 'perf trace'.

Attaching to a kprobe events will also be supported in the future.

Thanks,
Yang