commit | a32559120932231ebd6d19d3e8ae68a0fc502ef3 | [log] [tgz] |
---|---|---|
author | Cristian Marussi <cristian.marussi@arm.com> | Wed Jun 22 10:19:19 2022 +0100 |
committer | Yang Xu <xuyang2018.jy@fujitsu.com> | Wed Jul 06 17:36:04 2022 +0800 |
tree | e600209d55a82929e025beac8d03e78261e647f5 | |
parent | 1f2208c7c6fe679ea2e4834b9784e9492c795f66 [diff] |
Fix mountns01/02/03/04 final umounts using more peculiar dir names Running LTP20220527 release it appears that the recently re-written tests mountns02/03/04 can now throw a warning on their final umount attempt in some setup: <<<test_output>>> tst_test.c:1526: TINFO: Timeout per run is 0h 00m 30s mountns04.c:38: TPASS: unbindable mount passed tst_device.c:395: TWARN: umount('A') failed with EINVAL mountns.h:36: TWARN: umount(A) failed: EINVAL (22) tst_device.c:434: TINFO: No device is mounted at B Moreover, the underlying safe_umount() then upgrades the TWARN emitted from tst_umount to a TBROK, so causing the test to completely fail: Summary: passed 1 failed 0 broken 0 skipped 0 warnings 2 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=4 corefile=no Even though the final SAFE_UMOUNTs in the test body properly unmount the test created mountpoints, the final cleanup functions, that finally check to see if those mountpoints are still mounted, can be fooled into falsely thinking that test-chosen mountpoints "A" or "B" are still there: this is due to the fact that the internal helper tst_is_mounted() uses a simple strstr() on /proc/mounts to check if a directory is still mounted and clearly the currently test-chosen names are far too much simple, being one-letter, and they can be easily matched by other unrelated mountpoints that happen to exist on a specific setup. Use a more peculiar naming for the test chosen mountpoints and generalize accordingly all the comments. Cc: Andrea Cervesato <andrea.cervesato@suse.de> Cc: Cyril Hrubis <chrubis@suse.cz> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Yang Xu <xuyang2018.jy@fujitsu.com> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
Linux Test Project is a joint project started by SGI, OSDL and Bull developed and maintained by IBM, Cisco, Fujitsu, SUSE, Red Hat, Oracle and others. The project goal is to deliver tests to the open source community that validate the reliability, robustness, and stability of Linux.
The LTP testsuite contains a collection of tools for testing the Linux kernel and related features. Our goal is to improve the Linux kernel and system libraries by bringing test automation to the testing effort. Interested open source contributors are encouraged to join.
Project pages are located at: http://linux-test-project.github.io/
The latest image is always available at: https://github.com/linux-test-project/ltp/releases
The discussion about the project happens at ltp mailing list: http://lists.linux.it/listinfo/ltp
The git repository is located at GitHub at: https://github.com/linux-test-project/ltp
The patchwork instance is at: https://patchwork.ozlabs.org/project/ltp/list/
Be careful with these tests!
Don't run them on production systems. Growfiles, doio, and iogen in particular stress the I/O capabilities of systems and while they should not cause problems on properly functioning systems, they are intended to find (or cause) problems.
If you have git, autoconf, automake, m4, pkgconf / pkg-config, libc headers, linux kernel headers and other common development packages installed (see INSTALL and ci/*.sh), the chances are the following will work:
$ git clone https://github.com/linux-test-project/ltp.git $ cd ltp $ make autotools $ ./configure
Now you can continue either with compiling and running a single test or with compiling and installing the whole testsuite.
For optional library dependencies look into scripts for major distros in ci/
directory. You can also build whole LTP with ./build.sh
script.
If you need to execute a single test you actually do not need to compile the whole LTP, if you want to run a syscall testcase following should work.
$ cd testcases/kernel/syscalls/foo $ make $ PATH=$PATH:$PWD ./foo01
Shell testcases are a bit more complicated since these need a path to a shell library as well as to compiled binary helpers, but generally following should work.
$ cd testcases/lib $ make $ cd ../commands/foo $ PATH=$PATH:$PWD:$PWD/../../lib/ ./foo01.sh
Open Posix Testsuite has it's own build system which needs Makefiles to be generated first, then compilation should work in subdirectories as well.
$ cd testcases/open_posix_testsuite/ $ make generate-makefiles $ cd conformance/interfaces/foo $ make $ ./foo_1-1.run-test
$ make $ make install
This will install LTP to /opt/ltp
.
doc/mini-howto-building-ltp-from-git.txt
.INSTALL
and ./configure --help
.Some tests will be disabled if the configure script can not find their build dependencies.
TCONF
due to a missing component, check the ./configure
output.INSTALL
.To run all the test suites
$ cd /opt/ltp $ ./runltp
Note that many test cases have to be executed as root.
To run a particular test suite
$ ./runltp -f syscalls
To run all tests with madvise
in the name
$ ./runltp -f syscalls -s madvise
Also see
$ ./runltp --help
Test suites (e.g. syscalls) are defined in the runtest directory. Each file contains a list of test cases in a simple format, see doc/ltp-run-files.txt.
Each test case has its own executable or script, these can be executed directly
$ testcases/bin/abort01
Some have arguments
$ testcases/bin/mesgq\_nstest -m none
The vast majority of test cases accept the -h (help) switch
$ testcases/bin/ioctl01 -h
Many require certain environment variables to be set
$ LTPROOT=/opt/ltp PATH="$PATH:$LTPROOT/testcases/bin" testcases/bin/wc01.sh
Most commonly, the path variable needs to be set and also LTPROOT
, but there are a number of other variables, runltp
usually sets these for you.
Note that all shell scripts need the PATH
to be set. However this is not limited to shell scripts, many C based tests need environment variables as well.
For more info see doc/user-guide.txt
or online at https://github.com/linux-test-project/ltp/wiki/User-Guidelines.
Network tests require certain setup, described in testcases/network/README.md
(online at https://github.com/linux-test-project/ltp/tree/master/testcases/network).
Before you start you should read following documents:
doc/test-writing-guidelines.txt
doc/build-system-guide.txt
doc/library-api-writing-guidelines.txt
There is also a step-by-step tutorial:
doc/c-test-tutorial-simple.txt
If something is not covered there don't hesitate to ask on the LTP mailing list. Also note that these documents are available online at:
Although we accept GitHub pull requests, the preferred way is sending patches to our mailing list.
It's a good idea to test patches on GitHub Actions before posting to mailing list. Our GitHub Actions setup covers various architectures and distributions in order to make sure LTP compiles cleanly on most common configurations. For testing you need to just to push your changes to your own LTP fork on GitHub.