Re: [PATCH v8 5/5] selftests/ftrace: Add a stackmap basic functionality test

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] selftests/ftrace: clear_trace() race after enable_tracing() in
  stackmap test
--

commit dccfeaafcec2ce879803de3ca52edb3da1c1743d
Author: Pengfei Li <lipengfei28@xiaomi.com>

selftests/ftrace: Add a stackmap basic functionality test

This commit adds an ftrace selftest that verifies stack_map deduplication,
reset behavior with active and stopped writers, statistics reporting, and
deferred freeing with open readers.

> diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/stackmap-basic.tc b/tools/testing/selftests/ftrace/test.d/ftrace/stackmap-basic.tc
> new file mode 100644
> index 0000000000000..f5d1ebd8728e8
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/ftrace/stackmap-basic.tc

[ ... ]

> +    echo 0 > stack_map || fail "stopped-writer verification reset failed"
> +    n=$(records)
> +    [ "$n" -eq 0 ] || fail "stopped-writer reset left $n records"
> +    n=$(stat_val entries)
> +    [ "$n" -eq 0 ] || fail "stopped-writer reset left stat entries $n"
> +
> +    kill -CONT "$worker" || fail "could not resume reset workload"
> +    enable_tracing
> +    i=$((i + 1))
> +done
> +
> +# Reset leaves old cookies in the buffer; drop them.
> +clear_trace
> +
> +# Wait until some record is hit twice, i.e. reused.
> +i=0
> +while [ "$i" -lt 100 ]; do
> +    [ "$(max_ref)" -ge 2 ] && break
> +    sleep 0.1
> +    i=$((i + 1))
> +done
> +
> +kill -STOP "$worker" || fail "could not stop final reset workload"
> +wait_for_worker_stopped ||
> +    fail "final reset workload did not enter the stopped state"
> +disable_tracing

[Severity: Low]
Can clear_trace race with the resumed worker and leave the trace ring
buffer empty when max_ref reaches 2?

On the last iteration of the reset loop, the worker is resumed and tracing
is enabled before clear_trace runs.  Any sched_switch events recorded in
that window populate stack_map and increment ref counts, and clear_trace
then wipes their <stack_id N gen G> entries from trace without resetting
stack_map.  If a stack reaches ref >= 2 before clear_trace finishes and no
further sched_switch event occurs before disable_tracing, the loop exits
immediately and the later check for <stack_id N gen G> events in trace
fails:

tools/testing/selftests/ftrace/test.d/ftrace/stackmap-basic.tc:
    trace_pairs=$(sed -n \
        's/.*<stack_id \([0-9][0-9]*\) gen \([0-9][0-9]*\)>.*/\1:\2/p' \
        trace | sort -u)
    [ -n "$trace_pairs" ] ||
        fail "trace has no <stack_id N gen G> events after active-writer reset"

Calling clear_trace while the worker is still stopped and tracing is
disabled (before resuming the worker on the final iteration, or by
stopping it around clear_trace and resetting stack_map) would avoid this
window.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261107055139.3138633-1-lipengfei28@xiaomi.com?part=5