aboutsummaryrefslogtreecommitdiff
path: root/tests/run_tests.py
AgeCommit message (Collapse)Author
2012-11-08Make custom linker scripts configurableGerald Schaefer
This patch introduces a CUSTOM_LDSCRIPTS variable in the Makefile as preparation for enabling libhugetlbfs linking on architectures w/o providing (deprecated) custom linker scripts. Setting it to "no" will prevent building and running the test cases requiring custom linker scripts, and issue an error message in ld.hugetlbfs when option --hugetlbfs-link is being used. It is set to "yes" by default for all architectures, which means no change to the current behaviour as far as "make" is concerned. A new option -l is added to run_tests.py, enabling the old-style linking tests. This means that the default for running run_tests.py directly is now changed to skip the old-style linking tests. Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2012-11-06build 4G-edge testcases as -staticJan Stancek
huge_at_4GB_normal_below, huge_below_4GB_normal_above, straddle_4GB are tests to test corner cases on powerpc. powerpc manages memory using slices: low (0-4G) and high (4G-). These tests are using MAP_FIXED and try to mmap hugepage at various locations. Issue is that kernel or ld.so can already mmaped region that these tests want to use: # ./obj64/straddle_4GB Starting testcase "./obj64/straddle_4GB", pid 25949 Mapping without MAP_FIXED at ff000000...got 0xefffe000000 instead, never mind Mapping with MAP_FIXED at ff000000 FAIL mmap() FIXED failed: Device or resource busy Looking at mappings prior to failed mmap, there are already some libraries mapped to first high slice (0). Without patch: 10010000-10020000 r--p 00000000 fd:01 2893006 /root/libhugetlbfs/tests/obj64/straddle_4GB 10020000-10030000 rw-p 00010000 fd:01 2893006 /root/libhugetlbfs/tests/obj64/straddle_4GB 8015160000-8015190000 r-xp 00000000 fd:01 1857222 /usr/lib64/ld-2.15.so 8015190000-80151a0000 r--p 00020000 fd:01 1857222 /usr/lib64/ld-2.15.so 80151a0000-80151b0000 rw-p 00030000 fd:01 1857222 /usr/lib64/ld-2.15.so 80151d0000-8015390000 r-xp 00000000 fd:01 1857223 /usr/lib64/libc-2.15.so 8015390000-80153a0000 r--p 001b0000 fd:01 1857223 /usr/lib64/libc-2.15.so 80153a0000-80153c0000 rw-p 001c0000 fd:01 1857223 /usr/lib64/libc-2.15.so 80153c0000-80153e0000 r-xp 00000000 fd:01 1835789 /usr/lib64/libpthread-2.15.so 80153e0000-80153f0000 r--p 00010000 fd:01 1835789 /usr/lib64/libpthread-2.15.so 80153f0000-8015400000 rw-p 00020000 fd:01 1835789 /usr/lib64/libpthread-2.15.so 8015400000-8015410000 r-xp 00000000 fd:01 1842374 /usr/lib64/libdl-2.15.so 8015410000-8015420000 r--p 00000000 fd:01 1842374 /usr/lib64/libdl-2.15.so 8015420000-8015430000 rw-p 00010000 fd:01 1842374 /usr/lib64/libdl-2.15.so 10022e00000-10022e30000 rw-p 00000000 00:00 0 [heap] fff8e650000-fff8e670000 r-xp 00000000 fd:01 1837902 /usr/lib64/libhugetlbfs.so fff8e670000-fff8e680000 r--p 00010000 fd:01 1837902 /usr/lib64/libhugetlbfs.so fff8e680000-fff8e690000 rw-p 00020000 fd:01 1837902 /usr/lib64/libhugetlbfs.so fff8e690000-fff8e6a0000 r-xp 00000000 fd:01 1842940 /usr/lib64/libhugetlbfs_privutils.so fff8e6a0000-fff8e6b0000 r--p 00000000 fd:01 1842940 /usr/lib64/libhugetlbfs_privutils.so fff8e6b0000-fff8e6c0000 rw-p 00010000 fd:01 1842940 /usr/lib64/libhugetlbfs_privutils.so fff8e6c0000-fff8e6d0000 rw-p 00000000 00:00 0 fff8e6d0000-fff8e6f0000 r-xp 00000000 00:00 0 [vdso] fffc7110000-fffc7140000 rw-p 00000000 00:00 0 [stack] This patch builds 3 mentioned testcases as -static, which increases chances, that slices around 4GB boundary will be free. With patch: 10000000-100d0000 r-xp 00000000 fd:01 1966884 /root/libhugetlbfs/tests/obj64/straddle_4GB_static 100d0000-100f0000 rw-p 000c0000 fd:01 1966884 /root/libhugetlbfs/tests/obj64/straddle_4GB_static 100f0000-10100000 rw-p 00000000 00:00 0 10019550000-10019580000 rw-p 00000000 00:00 0 [heap] fffac380000-fffac390000 rw-p 00000000 00:00 0 fffac390000-fffac3b0000 r-xp 00000000 00:00 0 [vdso] fffdca10000-fffdca40000 rw-p 00000000 00:00 0 [stack] Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2011-02-23Allow actions to be restricted to certain programsAndrew Hastings
By default, libhugetlbfs will act on any program that it is loaded with, either via LD_PRELOAD or by explicitly linking with -lhugetlbfs. There are situations in which it is desirable to restrict libhugetlbfs' actions to specific programs. For example, some ISV applications are wrapped in a series of scripts that invoke bash, python, and/or perl. It is more convenient to set the environment variables related to libhugetlbfs outside of the wrapper scripts, yet this has the unintended and undesirable consequence of causing the script interpreters to use and consume hugepages. Often there is no obvious benefit to causing the script interpreters to use hugepages, and there is a clear disadvantage: fewer hugepages are available to the actual application. To address this scenario, add a HUGETLB_RESTRICT_EXE environment variable. If this variable is set, libhugetlbfs will restrict its actions to only those programs named in HUGETLB_RESTRICT_EXE. (If not set, libhugetlbfs will attempt to apply the requested actions to all programs.) For example, HUGETLB_RESTRICT_EXE="hpcc:long_hpcc" will restrict libhugetlbfs' actions to programs named /home/fred/hpcc and /bench/long_hpcc but will not affect /usr/bin/hpcc_no. Based on a patch originally authored by Dean Luick <luick@cray.com>. Signed-off-by: Andrew Hastings <abh@cray.com> on behalf of Cray Inc. Signed-off-by: Eric B Munson <emunson@mgebm.net>
2011-02-23tests: add support for static linkingAndrew Hastings
Add general support for static linking to the test suite. Build a static version of the shmoverride_linked test; this acts as a test case for a recent patch that allows shmget() to be used in static executables linked against libhugetlbfs. Correct runtests.py to run all cases of shmoverride: with and without LD_PRELOAD, with and without HUGETLB_SHM, with and without prelinking. Signed-off-by: Andrew Hastings <abh@cray.com> on behalf of Cray Inc. Signed-off-by: Eric B Munson <emunson@mgebm.net>
2010-02-04Make run_tests.py detect valid word sizesEric B Munson
Currently run_tests.py blindly tries both 32 and 64 bit tests regardless of what is available. This patch makes run_tests.py detect available word sizes before starting the tests. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2010-01-27Fix run_test_prog to handle OSErrorEric B Munson
Currently run_test_prog is unprotected from the OSError exception. This patch makes run_test_prog return an error value instead of having the exception kill the entire process. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-12-09Add wrappers for unsafe kernel tests.Eric B Munson
This patch adds wrapper scripts for the three new tests added by David Gibson. These tests are know unsafe for mainline and will be skipped on kernels < 2.6.33. This test will need to be updated to match the version that gets the fix for each particular bug. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-12-09Add testcases for buggy mremap() behavioursDavid Gibson
Al Viro recently discovered several bugs in the behaviour of mremap() that can cause crashes on architectures with holes in the address space (like ia64) and on powerpc with it's distinct page size "slices". This patch adds three new testcases to tickle some of these bugs (aimed chiefly at the powerpc manifestation, it may or may not also trip on other archs). Since these testcases will crash current kernels, we probably don't want to merge this until we can protect them with a kernel version test, like other dangerous testcases. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-11-19Don't try to test multiple pagesizes for SysV shmDavid Gibson
Currently, run_tests.py attempts to run each test case for each available page size and word size. It does this by setting the HUGETLB_DEFAULT_PAGE_SIZE environment variable to instruct the testcase's instance of libhugetlbfs to use the specified pagesize. However some of the testcases use shmget() with the SHM_HUGETLB flag to obtain hugepage backed memory, rather than mmap() or the libhugetlbfs interfaces. This means of obtaining hugepage memory has no way to specify the pagesize, and will always use the system default huge page size. Therefore, running the test multiple times when it won't actually use a different pagesize is silly. Furthermore in some of the cases, using the non-default sizes results in test failures (because we don't allocate as much memory as we expect) which have to be suppressed with a wrapper script which turns them into expected failures. This patch, therefore, alters run_tests.py to run the shm only tests with only the default page size. This is accomplished with a new helper function 'do_shm_test', which also folds in the setting and restoring of the shmmax limit for added convenience. The no longer necessary wrappers for shm-fork and shm-getraw are removed. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-11-19Add paranoid checking of hugepage pool sizesDavid Gibson
This patch adds code to the run_tests.py script to check the state of all the hugepage pools before and after each testcase. When turned on (with the new '-c' option to run_tests.py), it will report an error if the pool sizes are different after the test than before. Obviously this can report bogus errors if other programs are using hugepages on the system, or if dynamic pools are enabled. Nonetheless it can be useful it can be useful for detecting and tracking down subtle kernel bugs which result in misaccounting of the pool state (I've used it to debug such problems in a new hugepage port). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-08-24Make tests for SPECIAL in linker scripts safe against cross-compilesDavid Gibson
Currently, run_tests.py invokes gcc to obtain the standard linker script, in order to tell if the old-style linker-script based relink testcases can work. But this a) assumes that a compiler and linker is available and b) assumes that it has the same linker script as when the testsuite was compiled. If the testsuite is compiled on one machine, then copied to another for execution, either of these could be false. This is a useful common case if the machine we're testing on is highly constrained (e.g. an embedded machine, or a simulator). What we really want is the linker script of the toolchain which was used to build the testsuite. Therefore this patch removes the test-time invocation of gcc. Instead, gcc is invoked to dump the linker script to a file when the testsuite is built, then run_tests.py reads this file back in and checks it for the appropriate linker magic. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-08-24Don't use a shell to invoke testcasesDavid Gibson
The old run_tests.sh was replaced with run_tests.py quite a while ago, but in some places it still shows its shell origins. In particular, rather than having the Python script directly execute the individual testcase binaries, a shell is invoked to execute each one. Environment variables are passed in as parts of the shell command line instead of being directly provided and so forth. That approach is a bit aesthetically displeasing, plus it slows down operation of the testsuite. The slowdown is usually barely measureable, however on really slow machines (such as simulators) or on kernels with lots of debugging added, the extra context switches can be an annoying delay. Therefore, this patch reworks the test script to directly invoke each testcase executable, without invoking an intermediate shell. This is done through a new run_test_prog() function which combines the existing bash() and cmd_env() functions. The bash() which runs through a shell is still used in a few places where we invoke whole shell pipelines, but it's no longer used on each testcase. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-08-21Make run_tests.py set rlimits for mlock and stack_grow_into_huge testsDavid Gibson
The mlock and stack_grow_into_huge testcases require very large amounts of locked memory and stack space respectively - larger than the default ulimits set by some distros. Originally, I avoided having the testcases or the wrapper script set the ulimits for these tests so that the whole test script could be run without root. However, these days the testsuite does require root and uses it to set some other system limits (e.g. the shm segment size limits). So, it's silly not to set the stack and locked memory limits for these tests as well. Therefore, this patch adds code to temporarily adjust the relevant rlimits around these testcases. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-08-21libhugetlbfs: Fix some small errors / warts in run_tests.pyDavid Gibson
This fixes one real bug in run_tests.py and a couple of other places where we do things in a silly way. The real bug is that we clearly want to use the current libhugetlbfs binaries and libraries to run the test, so they should be added to the front of the path, not the back as cmd_env() currently does. In the same piece of code we use Python's `` operators for no good reason, since the string formatting operation we're already using will encode the bits value properly. cmd_env() also takes an optional pagesize parameter. The only time it's not supplied is when it's used to invoke hugeadm, which doesn't really suit use of cmd_env() anyway. So, this patch makes that parameter mandatory which simplifies the logic a bit (in fact that test logic was also wrong, but it didn't really matter). Finally, in bash() we use the dictionary's update() method instead of the manual equivalent. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-08-19Fix inner loop in elflink_and_share_test et al.David Gibson
The run_tests.py functions elflink_and_share_test and elflink_rw_and_share_test have an inner loop which runs exactly the same tests twice. It looks like it's instead supposed to run them with HUGETLB_SHARE=0 then HUGETLB_SHARE=1. This patch fixes up the Python code so that that's actually what happens. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-05-27Add -f option to run_test.py to force dangerous tests to runEric B Munson
Currently the readahead_reserve and [m|f]advise tests are all skipped if the running kernel is earlier than 2.6.30 because they can cause the machine to hang. This patch adds a -f switch to run_tests.py that allows the user to override this behavior. If -f is specified to run_tests.py these potentially dangerous tests will be run. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-05-18Add a test that mixes permissions on shared memory segmentsMel Gorman
Due to some confustion between VM_SHARED and VM_MAYSHARE in hugetlbfs, it is possible for hugepage reservations to get leaked. By using VM_SHARED, hugetlbfs will treat a shmem segment mapped read-only as if it was MAP_PRIVATE. This patch adds a test that checks if the kernel is vunerable to this bug. Note if this test fails, the system may no longer be usable for hugepage testing as the system will always think it has insufficient pages. A patch is currently being tested for this bug but no fix is merged upstream yet. Signed-off-by: Mel Gorman <mel@csn.ul.ie> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-05-13Wrapping tests to prevent machine hangsEric B Munson
The readahead, madvise, and the fadvise tests can all hang the running machine if the kernel bug they are testing is present. This patch wraps these tests so that they fail without running if the kernel version is less than 2.6.30. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com> Acked-by: Mel Gorman <mel@csn.ul.ie>
2009-05-07Add a regression test for leakingreserve count due to fadvise and readaheadMel Gorman
Use of fadvise() or readahead() on a hugetlbfs-backed memory region can result in reservations being leaked and in some cases the kernel triggering a BUG. This patch adds a regression tests for these conditions. Signed-off-by: Mel Gorman <mel@csn.ul.ie> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-05-07Add a regression test for leakingreserve count due to madvise() V2Mel Gorman
Use of madvise() on a hugetlbfs-backed memory region can result in reservations being leaked. This affects recent kernels (e.g. 2.6.29) but is fixed by commit a425a638c858fd10370b573bde81df3ba500e271. This patch adds a regression test for the bug. Changelog since V1 o Add a note on what kernel commit fixes the bug Signed-off-by: Mel Gorman <mel@csn.ul.ie> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-02-25Wrapping counters test for expected failureEric B Munson
The counters test depends on huge page overcommit which was not available until 2.6.24. This patch wraps the test to make runs on earlier kernels expected failures. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-02-19Add error checking if there is no hugetlbfs mount or huge pages availableEric B Munson
This patch makes the test harness print a nicer message if there are no available pagesizes. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-02-11Wrap the shm-fork and shm-getraw tests for expected failuresEric B Munson
The new test suite tries to run all tests with all available page sizes. This will be a problem with the shm-fork and shm-getraw tests as the shmget interface will only work with the default page, this patch wraps the tests to make the runs with pages sizes other than the default expected failures. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-01-30Rework test suite for multiple huge page size testingAdam Litke
Now that libhugetlbfs can work with multiple huge page sizes, testing this support has become a priority. The following patch enables automatic testing of page sizes that are mounted and have at least one page allocated. Care is taken to assure that only valid combinations are tested. For example, 32bit tests are not run with 16GB pages. Following the run, a summary of all page sizes tested is printed. The following is some example output of the new script: ********** TEST SUMMARY * 64K 16M 16G * 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit * Total testcases: 86 89 86 89 0 89 * Skipped: 20 0 20 0 0 0 * PASS: 59 75 62 85 0 49 * FAIL: 5 6 1 1 0 29 * Killed by signal: 0 0 0 0 0 0 * Bad configuration: 2 2 3 3 0 10 * Expected FAIL: 0 0 0 0 0 0 * Unexpected PASS: 0 0 0 0 0 0 * Strange test result: 0 6 0 0 0 1 ********** Script programming language conversion alert: This patch rewrites run_tests.sh in python. I already anticipate the "why change languages" comments so I come prepared with justification for the conversion. Our test harness has extended beyond simply executing a list of test cases and dumping the output to stdout. The data set for the test summary is now three-dimensional. It is indexed by result type (total tests, total passed, etc), word size, and now page size. The simple arrays in bash are not up to the task. As the number of tests that are run increases, so does the challenge of presenting the results in a meaningful, easy to digest format. Shell scripts lack the output formatting constructs that are present in languages such as Python and that make flexible output formatting possible. For these reasons (and the guarantee that the test harness will need to get even more sophisticated in the future), I made the inevitable decision to cut over to Python now. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com> Signed-off-by: Adam Litke <agl@us.ibm.com>