mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2026-04-03 12:05:13 +02:00
b6f446e12e
[ Upstream commitb889b4fb4c] The func_traceonoff_triggers.tc sometimes goes to fail on my board, Kunpeng-920. [root@localhost]# ./ftracetest ./test.d/ftrace/func_traceonoff_triggers.tc -l fail.log === Ftrace unit tests === [1] ftrace - test for function traceon/off triggers [FAIL] [2] (instance) ftrace - test for function traceon/off triggers [UNSUPPORTED] I look up the log, and it shows that the md5sum is different between csum1 and csum2. ++ cnt=611 ++ sleep .1 +++ cnt_trace +++ grep -v '^#' trace +++ wc -l ++ cnt2=611 ++ '[' 611 -ne 611 ']' +++ cat tracing_on ++ on=0 ++ '[' 0 '!=' 0 ']' +++ md5sum trace ++ csum1='76896aa74362fff66a6a5f3cf8a8a500 trace' ++ sleep .1 +++ md5sum trace ++ csum2='ee8625a21c058818fc26e45c1ed3f6de trace' ++ '[' '76896aa74362fff66a6a5f3cf8a8a500 trace' '!=' 'ee8625a21c058818fc26e45c1ed3f6de trace' ']' ++ fail 'Tracing file is still changing' ++ echo Tracing file is still changing Tracing file is still changing ++ exit_fail ++ exit 1 So I directly dump the trace file before md5sum, the diff shows that: [root@localhost]# diff trace_1.log trace_2.log -y --suppress-common-lines dockerd-12285 [036] d.... 18385.510290: sched_stat | <...>-12285 [036] d.... 18385.510290: sched_stat dockerd-12285 [036] d.... 18385.510291: sched_swit | <...>-12285 [036] d.... 18385.510291: sched_swit <...>-740 [044] d.... 18385.602859: sched_stat | kworker/44:1-740 [044] d.... 18385.602859: sched_stat <...>-740 [044] d.... 18385.602860: sched_swit | kworker/44:1-740 [044] d.... 18385.602860: sched_swit And we can see that <...> filed be filled with names. We can strip off the names there to fix that. After strip off the names: kworker/u257:0-12 [019] d..2. 2528.758910: sched_stat | -12 [019] d..2. 2528.758910: sched_stat_runtime: comm=k kworker/u257:0-12 [019] d..2. 2528.758912: sched_swit | -12 [019] d..2. 2528.758912: sched_switch: prev_comm=kw <idle>-0 [000] d.s5. 2528.762318: sched_waki | -0 [000] d.s5. 2528.762318: sched_waking: comm=sshd pi <idle>-0 [037] dNh2. 2528.762326: sched_wake | -0 [037] dNh2. 2528.762326: sched_wakeup: comm=sshd pi <idle>-0 [037] d..2. 2528.762334: sched_swit | -0 [037] d..2. 2528.762334: sched_switch: prev_comm=sw Link: https://lore.kernel.org/r/20230818013226.2182299-1-zouyipeng@huawei.com Fixes:d87b29179a("selftests: ftrace: Use md5sum to take less time of checking logs") Suggested-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Yipeng Zou <zouyipeng@huawei.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Linux Ftrace Testcases
This is a collection of testcases for ftrace tracing feature in the Linux
kernel. Since ftrace exports interfaces via the debugfs, we just need
shell scripts for testing. Feel free to add new test cases.
Running the ftrace testcases
============================
At first, you need to be the root user to run this script.
To run all testcases:
$ sudo ./ftracetest
To run specific testcases:
# ./ftracetest test.d/basic3.tc
Or you can also run testcases under given directory:
# ./ftracetest test.d/kprobe/
Contributing new testcases
==========================
Copy test.d/template to your testcase (whose filename must have *.tc
extension) and rewrite the test description line.
* The working directory of the script is <debugfs>/tracing/.
* Take care with side effects as the tests are run with root privilege.
* The tests should not run for a long period of time (more than 1 min.)
These are to be unit tests.
* You can add a directory for your testcases under test.d/ if needed.
* The test cases should run on dash (busybox shell) for testing on
minimal cross-build environments.
* Note that the tests are run with "set -e" (errexit) option. If any
command fails, the test will be terminated immediately.
* The tests can return some result codes instead of pass or fail by
using exit_unresolved, exit_untested, exit_unsupported and exit_xfail.
Result code
===========
Ftracetest supports following result codes.
* PASS: The test succeeded as expected. The test which exits with 0 is
counted as passed test.
* FAIL: The test failed, but was expected to succeed. The test which exits
with !0 is counted as failed test.
* UNRESOLVED: The test produced unclear or intermidiate results.
for example, the test was interrupted
or the test depends on a previous test, which failed.
or the test was set up incorrectly
The test which is in above situation, must call exit_unresolved.
* UNTESTED: The test was not run, currently just a placeholder.
In this case, the test must call exit_untested.
* UNSUPPORTED: The test failed because of lack of feature.
In this case, the test must call exit_unsupported.
* XFAIL: The test failed, and was expected to fail.
To return XFAIL, call exit_xfail from the test.
There are some sample test scripts for result code under samples/.
You can also run samples as below:
# ./ftracetest samples/
TODO
====
* Fancy colored output :)