| 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
| ||
|
Message-ID: <aFw0eBq2FBgy21IN@google.com> Date: Wed, 25 Jun 2025 10:40:08 -0700 From: Namhyung Kim <namhyung@...nel.org> To: Ian Rogers <irogers@...gle.com> Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>, Mark Rutland <mark.rutland@....com>, Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>, James Clark <james.clark@...aro.org>, Zhongqiu Han <quic_zhonhan@...cinc.com>, Yicong Yang <yangyicong@...ilicon.com>, linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, bpf@...r.kernel.org Subject: Re: [PATCH v1 0/4] Pipe mode header dumping and minor space saving On Tue, Jun 24, 2025 at 01:15:13PM -0700, Ian Rogers wrote: > On Tue, Jun 24, 2025 at 12:11 PM Namhyung Kim <namhyung@...nel.org> wrote: > > > > On Fri, Jun 06, 2025 at 11:12:34PM -0700, Ian Rogers wrote: > > > Pipe mode has no header and emits the data as if it were events. The > > > dumping of features was controlled by the --header/-I options which > > > makes little sense when they are events, normally traced when > > > dump_trace is true. Switch to making pipe feature events also be > > > traced with detail when other events are. > > > > I'm not sure I'm following. Are you saying the pipe mode doesn't > > support features with --header/-I option? > > No, in pipe mode it currently shows just PERF_RECORD_FEATURE or > PERF_RECORD_ATTR for the details of the events containing these > things. The reason being that the dumping is controlled by separate > header flags (--header and -I). In patch 1 the commit message shows > the before: > ``` > $ perf record -o - -a sleep 1 | perf script -D -i - > ... > 0x2c8@...e [0x54]: event: 80 > . > . ... raw event: size 84 bytes > . 0000: 50 00 00 00 00 00 54 00 05 00 00 00 00 00 00 00 P.....T......... > . 0010: 40 00 00 00 36 2e 31 35 2e 72 63 37 2e 67 61 64 @...6.15.rc7.gad > . 0020: 32 61 36 39 31 63 39 39 66 62 00 00 00 00 00 00 2a691c99fb...... > . 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0050: 00 00 00 00 .... > > 0 0 0x2c8 [0x54]: PERF_RECORD_FEATURE > ``` > > That is we have a feature "event" but there are no details there to > try to be able to understand the feature event. After the change this > becomes: > ``` > $ perf record -o - -a sleep 1 | perf script -D -i - > ... > 0x2c8@...e [0x54]: event: 80 > . > . ... raw event: size 84 bytes > . 0000: 50 00 00 00 00 00 54 00 05 00 00 00 00 00 00 00 P.....T......... > . 0010: 40 00 00 00 36 2e 31 35 2e 72 63 37 2e 67 61 64 @...6.15.rc7.gad > . 0020: 32 61 36 39 31 63 39 39 66 62 00 00 00 00 00 00 2a691c99fb...... > . 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0050: 00 00 00 00 .... > > 0 0 0x2c8 [0x54]: PERF_RECORD_FEATURE, # perf version : 6.15.rc7.gad2a691c99fb > ``` > > So now in the dump trace output I can see this was a feature for perf > version and what that value is. There are often multiple > PERF_RECORD_FEATURE and PERF_RECORD_ATTR "events" and so the extra > trace output helps in being able to work out what's going on. Thanks for the clarification, I was confused if it's fixing -I or -D. :) Namhyung
Powered by blists - more mailing lists