Re: [PATCH v7 33/59] perf check-perf-trace: Port check-perf-trace to use python module

sashiko-bot
2026-04-25T23:06:08Z

Sashiko AI review found 3 potential issue(s):
- [Medium] The script will crash with an unhandled TypeError when encountering samples for unknown or unsynthesized threads.
- [Low] The port silently drops the capability to decode kernel trace flags and GFP flags into human-readable strings.
- [Low] Unhandled events are summarized with an extraneous format wrapper, logging the internal `evsel` object string representation rather than bare event names.
--

commit 63e7f17c5646bdcb4eaaeba2e09a639c736980e9
Author: Ian Rogers <irogers@google.com>
perf check-perf-trace: Port check-perf-trace to use python module

Add a port of the check-perf-trace script that uses the perf python module
directly. This avoids creating intermediate dictionaries for all event fields,
which significantly improves the execution speed.

> diff --git a/tools/perf/python/check-perf-trace.py b/tools/perf/python/check-perf-trace.py
> new file mode 100755
> index 000000000000..7c1c7632a091
> --- /dev/null
> +++ b/tools/perf/python/check-perf-trace.py
> @@ -0,0 +1,113 @@
[ ... ]
> +def flag_str(event_name: str, field_name: str, value: int) -> str:
> + """Resolves flag values to strings."""
> + if event_name == "kmem__kmalloc" and field_name == "gfp_flags":
> + return f"0x{value:x}"

Does this drop the capability to decode flags into human-readable strings?

The legacy script used C-provided scripting core helpers to translate
raw integers into text, for example translating gfp_flags to GFP_KERNEL.
It looks like this port now just dumps the raw hexadecimal value instead.

> + return str(value)
> +
> +def print_header(event_name: str, sample: perf.sample_event) -> None:
> + """Prints common header for events."""
> + secs = sample.sample_time // 1000000000
> + nsecs = sample.sample_time % 1000000000
> + comm = session.find_thread(sample.sample_pid).comm() if session else "[unknown]"

Will this crash with an unhandled TypeError for unknown threads?

Looking at pyrf_session__find_thread in tools/perf/util/python.c, the
underlying machine__find_thread lookup raises a TypeError instead of
returning None when a thread is not found.

Encountering a sample for an untracked PID seems like it would crash
the script here instead of falling back to "[unknown]".

> + print(f"{event_name:<20} {sample.sample_cpu:5} {secs:05}.{nsecs:09} "
> + f"{sample.sample_pid:8} {comm:<20} ", end=' ')
[ ... ]
> +def process_event(sample: perf.sample_event) -> None:
> + """Callback for processing events."""
> + event_name = str(sample.evsel)

Does this cause unhandled events to be printed with an extraneous wrapper?

The string representation method for the evsel wrapper, pyrf_evsel__str,
returns strings formatted like "evsel(sched:sched_switch)".

Since this wrapped string is passed to trace_unhandled(), it seems the
unhandled events summary will print the wrapper text instead of just the
bare event names that the legacy version printed.

> + if event_name == "evsel(irq:softirq_entry)":
> + irq__softirq_entry(sample)
> + elif "evsel(kmem:kmalloc)" in event_name:
> + kmem__kmalloc(sample)
> + else:
> + trace_unhandled(event_name)

--
Sashiko AI review · https://sashiko.dev/#/patchset/20260425224951.174663-1-irogers@google.com?part=33