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: <20251229174901.0e62eab0@gandalf.local.home>
Date: Mon, 29 Dec 2025 17:49:01 -0500
From: Steven Rostedt <steven@...tedt.org>
To: Jiri Olsa <olsajiri@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux Trace Kernel
 <linux-trace-kernel@...r.kernel.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Ian Rogers <irogers@...gle.com>, Arnaldo Carvalho de Melo
 <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>
Subject: Re: [PATCH] tracing: Allow perf to read synthetic events

On Sun, 28 Dec 2025 23:59:34 +0100
Jiri Olsa <olsajiri@...il.com> wrote:

> hi,
> I don't see the crash, but perf record/script gives me 'FAILED TO PARSE' in perf script:
> 
>   # cd /sys/kernel/tracing
>   # echo 's:block_lat pid_t pid; u64 delta; unsigned long[] stack;' > dynamic_events
>   # echo 'hist:keys=next_pid:ts=common_timestamp.usecs,st=common_stacktrace  if prev_state == 2' >> events/sched/sched_switch/trigger
>   # echo 'hist:keys=prev_pid:delta=common_timestamp.usecs-$ts,s=$st:onmax($delta).trace(block_lat,prev_pid,$delta,$s)' >> events/sched/sched_switch/trigger
>   # echo 1 > events/synthetic/block_lat/enable
> 
>   # perf record -e 'synthetic:block_lat' -a
>   ^C[ perf record: Woken up 1 times to write data ]
>   [ perf record: Captured and wrote 0.259 MB perf.data (1 samples) ]
>   # perf script
>   kworker/u33:2-w     244 [000]  1707.836263: synthetic:block_lat: [FAILED TO PARSE] pid=244 delta=21 stack=ARRAY[0b, 00, 00, 00, 00, 00, 00, 00, 1d, 72, 9d, 82, ff, ff, ff, ff, 0d, 7d, 9d, 82, ff, ff, ff, ff, 3d, 3d, 9e, 82, ff, ff, ff, ff, 05, 91, 9d, 82, ff, ff, ff, ff, 40, 7a, 42, 81, ff, ff, ff, ff, 5e, f4, 0c, 82, ff, ff, ff, ff, 43, 8d, 0c, 82, ff, ff, ff, ff, 82, 2d, 89, 81, ff, ff, ff, ff, 9b, 39, 89, 81, ff, ff, ff, ff, a6, 5a, 9c, 82, ff, ff, ff, ff, 2f, 01, 00, 81, ff, ff, ff, ff]
> 
> not sure it's fixed in the latest libtraceevent, mine is
>   libtraceevent-1.8.4-3.fc42.x86_64

Yeah, it's not supported yet by libtraceevent (fails for trace-cmd record
as well). But this should be easily fixed:

 ># trace-cmd list -e block_lat -F --full
 system: synthetic
 name: block_lat
 ID: 1871
 format:
	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
	field:int common_pid;	offset:4;	size:4;	signed:1;

	field:pid_t pid;	offset:8;	size:4;	signed:1;
	field:u64 delta;	offset:16;	size:8;	signed:0;
	field:__data_loc unsigned long[] stack;	offset:24;	size:8;	signed:1;

 print fmt: "pid=%d delta=%llu stack=%s", REC->pid, REC->delta, __get_stacktrace(stack)

Looks like I only need to add "__get_stacktrace()" to the libtraceevent parsing.

Thanks,

-- Steve


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ