On 2025/7/11 3:34, Steven Rostedt wrote:
On Thu, 10 Jul 2025 13:01:34 +0000 Tengda Wu wutengda@huaweicloud.com wrote:
Fixes: 1a4ea83a6e67 ("selftests/ftrace: Limit length in subsystem-enable tests") Signed-off-by: Tengda Wu wutengda@huaweicloud.com
.../selftests/ftrace/test.d/event/subsystem-enable.tc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc index b7c8f29c09a9..3a28adc7b727 100644 --- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc +++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc @@ -19,8 +19,8 @@ echo 'sched:*' > set_event yield count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` -if [ $count -lt 3 ]; then
- fail "at least fork, exec and exit events should be recorded"
+if [ $count -eq 0 ]; then
- fail "none of scheduler events are recorded"
fi do_reset @@ -30,8 +30,8 @@ echo 1 > events/sched/enable yield count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` -if [ $count -lt 3 ]; then
- fail "at least fork, exec and exit events should be recorded"
+if [ $count -eq 0 ]; then
- fail "none of scheduler events are recorded"
So if there's a bug that causes the system enable to only enable a single event, this will no longer catch it?
I rather not let the slide.
Can you test this to see if this works for you?
-- Steve
diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc index b7c8f29c09a9..46a9e6d92730 100644 --- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc +++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc @@ -14,11 +14,32 @@ fail() { #msg exit_fail } +check_unique() {
- cat trace_pipe | grep -v '^#' | awk '
- BEGIN { cnt = 0; }
- {
for (i = 0; i < cnt; i++) {if (event[i] == $5) {break;}}if (i == cnt) {event[cnt++] = $5;if (cnt > 2) {exit;}}- }
- END {
printf "%d", cnt;- }'
+}
echo 'sched:*' > set_event yield -count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` +count=`check_unique` if [ $count -lt 3 ]; then fail "at least fork, exec and exit events should be recorded" fi @@ -29,7 +50,7 @@ echo 1 > events/sched/enable yield -count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` +count=`check_unique` if [ $count -lt 3 ]; then fail "at least fork, exec and exit events should be recorded" fi
The patch works well - after ~50 test iterations, we haven't observed any recurrence of the test case failures.
However, I'm concerned that using 'cat trace_pipe' (like the original 'cat trace' method) could bring back the stopping problem [1] on slower systems.
Could a slow trace_pipe reader (slower than sched event generation rate) reintroduce the original race condition?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Some test details:
$ ./ftracetest -vvv subsystem-enable.tc [...] + echo sched:* + yield + ping 127.0.0.1 -c 1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.538 ms
--- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 1ms rtt min/avg/max/mdev = 0.538/0.538/0.538/0.000 ms + check_unique + cat trace_pipe + grep -v ^# + awk BEGIN { cnt = 0; } { for (i = 0; i < cnt; i++) { if (event[i] == $5) { break; } } if (i == cnt) { event[cnt++] = $5; if (cnt > 2) { exit; } } } END { printf "%d", cnt; } + count=3 + [ 3 -lt 3 ] + do_reset [...]
Regards, Tengda