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 [off-list ref]
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.
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
+ 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