Re: [PATCH v9 8/9] perf scripts: Add perf-stuck, to tell where a running perf is stuck

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf-stuck.sh: progress log \r carriage returns corrupt terminal output
--

commit bef40c1a9b75b6852c5b823d7f7eb048553178f4
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf scripts: Add perf-stuck, to tell where a running perf is stuck

A perf that takes forever is hard to tell apart from one stuck in a
loop, and there is no way to see where without attaching gdb.
perf-stuck.sh samples a running process' /proc entries and its progress
line at a fixed interval, and with -g runs gdb when no progress is made
across two samples.

> diff --git a/tools/perf/scripts/perf-stuck.sh b/tools/perf/scripts/perf-stuck.sh
> new file mode 100755
> index 0000000000000..f9b545c107905
> --- /dev/null
> +++ b/tools/perf/scripts/perf-stuck.sh
[ ... ]
> +	progress=
> +	[ -n "$progress_log" ] && [ -s "$progress_log" ] && progress=$(tail -1 -- "$progress_log")

[Severity: Medium]
Since perf progress updates typically use carriage returns (\r) instead of
newlines to update in-place, will tail -1 read the entire sequence of
updates into memory?

Does this also fail to strip out the embedded \r characters from the
progress string?

[ ... ]
> +	printf '%s state=%s cpu=+%d (%d.%02ds) rss=%dkB stack=%s %s %s\n' \
> +	       "$(date +%T)" "$state" "$cpu_delta" \
> +	       $(( cpu_delta / hz )) $(( (cpu_delta % hz) * 100 / hz )) \
> +	       "$rss" "$stack_txt" "$stuck_txt" "${progress:-(no progress log)}"

[Severity: Medium]
Does printing the unsanitized progress string here cause the terminal cursor
to reset?

Because the embedded \r characters remain in the string, printing them will
overwrite and garble the previously printed diagnostic metrics (such as time,
CPU, state, RSS, and stack) on the terminal.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261004060457.3353-1-acme@kernel.org?part=8