aboutsummaryrefslogtreecommitdiff
path: root/tests
AgeCommit message (Collapse)Author
2013-03-09task-size-overrun: fix problem with dynamic pagetable upgrade on s390xGerald Schaefer
The strategy to find out TASK_SIZE won't work on s390x anymore, starting with kernel 3.9. We will dynamically increase the pagetable levels on s390x on access beyond TASK_SIZE, effectively increasing TASK_SIZE from 2^42 to 2^53, but /proc/self/maps won't reflect this. With the current strategy that means that find_task_size() would loop for a very long time, from 2^42 to 2^53. To fix this, increase addr in the loop for s390x as soon as we exceed the 2^42 limit. Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2013-02-23avoid calling munmap with zero lengthJan Stancek
mremap-fixed-huge-near-normal testcase mmaps 4*hpage_size - getpagesize() of anon shared memory. Then it finds area of 3 huge pages aligned to hpage_size and munmaps lower and upper areas: lower +----- 3*hpage_size -----+ upper / \/ \/ \ |--------|--------|--------|--------|--------| p q | p+xsize q+size If initial mmap will place whole area in such way, that lower or upper area size is zero, munmap fails with EINVAL and testcase fails. mmap(2): EINVAL (since Linux 2.6.12) length was 0. Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric Munson <emunson@bert.(none)>
2013-02-23ARM unit test fix.Steve Capper
Supply some ARM signal handler code for icache-hygiene, and an ARM icache flush function. Signed-off-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Eric Munson <emunson@bert.(none)>
2012-12-07Revert "exhaust malloc arenas before malloc tests"Eric B Munson
This reverts commit cdd2fa336d9980eb268a775b7cf9c49e3b698cd7. Conflicts: tests/hugetests.h tests/testutils.c With the removal of sscanf from the setup routines, the malloc tests now pass without having to exhaust small page allocations. Signed-off-by: Eric B Munson <emunson@mgebm.net> Cc: Jan Stancek <jstancek@redhat.com> Cc: Steve Capper <steve.capper@arm.com>
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>
2012-11-06fail test only when MAP_FIXED fails on free slicesJan 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 be already using region that these tests want to use. At the moment it ends with failure: # ./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). 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 checks that slices used by tests are actually free (not mapped). If they are not free and mmap fails, test will PASS as inconclusive. Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2012-11-06set slice boundary at runtimeJan Stancek
This testcase failed on some setups (ppc64): Starting testcase "./obj64/mremap-expand-slice-collision", pid 10840 do_readback(0x20001000000, 0x1000000, "huge above") do_readback(0x1ffffff0000, 0x10000, "normal below") Attempting to remap...disallowed do_readback(0x20001000000, 0x10000, "normal above") FAIL mmap(huge below): Device or resource busy Problem is that SLICE_BOUNDARY was hardcoded to 0x20000000000. When testcase tries to mmap huge page below this address (0x1ffff000000), it fails with EBUSY because there is already heap (0x1????000000) at this slice which may not be using huge pages. See also kernel commit. which introduced slices on powerpc: commit d0f13e3c20b6fb73ccb467bdca97fa7cf5a574cd Author: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: Tue May 8 16:27:27 2007 +1000 [POWERPC] Introduce address space "slices" This patch removes hardcoded SLICE_BOUNDARY address and introduces function to find two free neighbour slices at runtime. Slice boundary is then set to address between these slices. With patch: Starting testcase "./obj64/mremap-expand-slice-collision", pid 12768 can't use slice_boundary: 0x20000000000 using slice_boundary: 0x30000000000 do_readback(0x30001000000, 0x1000000, "huge above") do_readback(0x2ffffff0000, 0x10000, "normal below") Attempting to remap...disallowed do_readback(0x30001000000, 0x10000, "normal above") do_readback(0x2ffff000000, 0x1000000, "huge below") Attempting to remap...disallowed PASS Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2012-11-06mremap can't extend shared anon memoryJan Stancek
mremap-expand-slice-collision mmaps page of shared anon memory, which is then passed to mremap to extend this mapping to two pages: mremap(q, page_size, 2*page_size, 0); The mapping is extended, but backing shmem file is not, so accessing second page always fails with SIGBUS in do_readback(). Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2012-09-07limit core dumping for stack_grow_into_hugeJan Stancek
stack_grow_into_huge allocates large chunks on memory and do_child() will eventually fail with SIGSEGV. If system is set up to dump core, it can take significant time until this action is completed. For example if ABRT runs on such system, kernel is blocked on pipe_write for couple of minutes: # time ./obj64/stack_grow_into_huge Starting testcase "./obj64/stack_grow_into_huge", pid 24257 PASS real 29m12.060s user 0m0.013s sys 4m41.744s Sep 7 06:56:54 ibm-p720-01-lp3 abrt[24259]: Saved core dump of pid 24258 (/root/libhugetlbfs/tests/obj64/stack_grow_into_huge) to /var/spool/abrt/ccpp-2012-09-07-06:27:42-24258 (1098439983104 bytes) With patch: Starting testcase "./obj64/stack_grow_into_huge", pid 24384 PASS real 0m0.206s user 0m0.013s sys 0m0.193s Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2012-09-07dont include base_size in fake hugepagesizesJan Stancek
What is fake on one platform can be actual page_size on some other platform. This testcase failed on ppc64 with 64K pagesize: gethugepagesizes (16M: 32): FAIL Line 397: Duplicate size 65536 at 0/2 gethugepagesizes (16M: 64): FAIL Line 397: Duplicate size 65536 at 0/2 Reason is that getpagesizes() adds pagesize to page sizes from gethugetpagesizes(). This testcase fakes sysfs data, so there is 64K hugepage size and then getpagesizes() adds base_size to that, which is also 64K. Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2012-09-06exhaust malloc arenas before malloc testsJan Stancek
First allocation in malloc tests is just 1024 bytes. If there is enough free mem in malloc arenas, this first allocation can be satisfied without call to MORECORE() and testcase will fail. LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (2M: 64): FAIL Address is not hugepage When looking at output from HUGETLB_DEBUG=1 it appears that hook to __morecore doesn't work as there is no trace from hugetlbfs_morecore. This patch will keep malloc-ing 1-byte chunks of memory as long as it comes from '[heap]' or maximum is reached. This will force glibc to call MORECORE() before actual malloc/malloc_manysmall test begins. Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2012-09-06ignore return value from readahead()Jan Stancek
do_readahead() requires a_ops->readpage to be != NULL: 568 static ssize_t 569 do_readahead(struct address_space *mapping, struct file *filp, 570 pgoff_t index, unsigned long nr) 571 { 572 if (!mapping || !mapping->a_ops || !mapping->a_ops->readpage) 573 return -EINVAL; 574 575 force_page_cache_readahead(mapping, filp, index, nr); 576 return 0; 577 } but following commit removed readpage from hugetlbfs: commit f2deae9d4e70793568ef9e85d227abb7bef5b622 Author: Mel Gorman <mel@csn.ul.ie> Date: Wed May 13 15:56:10 2009 +0100 Remove implementation of readpage from the hugetlbfs_aops So this is going to always return EINVAL on patched kernels. Ignore return value, regardless of readahead() outcome testcase will still check if reservation counter gets corrupted. Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Eric B Munson <emunson@mgebm.net>
2011-12-07Replace fixed address shm attachment by an random oneBill Carson
Original fixed address at 0x80000000 will fail when calling shmat on ARM. Use the address system provide for us will prevent this failure. Moreover, add cleanup when shmat failed to release reserved huge pages otherwise paranoid pool check will fail on this. Signed-off-by: Bill Carson <bill4carson@gmail.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>
2011-01-21Store return value of ftruncate in icache-hygieneEric B Munson
When warn_unused_result is enabled there are several warnings about ignored return values of ftruncate in the icache-hygiene test. This patch contiunues to ignore the return value but stores it to quiet the compiler. Signed-off-by: Eric B Munson <emunson@mgebm.net>
2011-01-21tests/Makefile: add missing testsAndrew Hastings
Fix the libhugetlbfs test Makefile so the built-in test suite can correctly install and run the tests. - Several tests that require a wrapper are not in the general list of tests. They must be listed there for the wrapper Makefile code to operate correctly. - The test driver is now a python script, but the installer was still looking for a differently named bash script. 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>
2010-11-29Convert heap tests to use get_mapping_page_sizeEric B Munson
Convert all the heap based tests to use get_mapping_page_size to check if a mapping is backed by huge pages now that morecore uses MAP_HUGETLB. Signed-off-by: Eric B Munson <emunson@mgebm.net>
2010-11-29Convert the get_huge_pages tests to use new smaps testEric B Munson
If get_huge_pages uses MAP_HUGETLB to create a new huge page region, the old test_addr_huge function will claim the mapping is not on a huge page. This patch changes the test to use the new get_mapping_page_size method. Signed-off-by: Eric B Munson <emunson@mgebm.net>
2010-11-29Read /proc/self/smaps to test page size of mappingEric B Munson
When MAP_HUGETLB is used, the standard test for a mapping being backed by huge pages fails because the mapping will not be on hugetlbfs. Instead of testing the filesystem backing the mapping, this patch adds a check of reported MMU page size from /proc/self/smaps. get_mapping_page_size returns the page size that is being used for the specified mapping in bytes. Signed-off-by: Eric B Munson <emunson@mgebm.net> Acked-by: Mel Gorman <mel@csn.ul.ie>
2010-11-17Rename variable in inline functionEric B Munson
hpage_size is a fairly common variable name in this library so it is dangerous to use it in an inlined function. This patch renames it to __hpage_size to avoid name collisions. Signed-off-by: Eric B Munson <emunson@mgebm.net>
2010-06-01Fix bug in gethugepagesizes testcaseDavid Gibson
The gethugepagesizes testcase tests the calls to retreieve the available page sizes against faked up sysfs contents. This includes testing that the gethugepagesizes() call doesn't return more entries than the maximum it's given (which might clobber memory). However, it does this incorrectly: specifically, validate_sizes() checks that the n returned entries exactly match the first n expected entries, even when the maxmum number of entries to return is smaller than the total number of pagesizes available. gethugepagesizes() is not guaranteed to return the pagesizes in any particular order (based as it is on getting a directory listing), so this test will generate bogus failures. In fact, for the case where the given maximum is smaller than the total number of pagesizes, the test should accept as a pass any subset of the expected pagesizes in the returned results. This patch makes the correction. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2010-02-11parent 48b4959e950ca54937e70152e28f27b8d1157e8b (2.7)Jan Engelhardt
commit 02252c829111e6a68b465f8f1da74098c9e3491f Author: Jan Engelhardt <jengelh@medozas.de> Date: Tue Feb 9 12:42:57 2010 +0100 tests/icache-hygiene: allow compilation on SPARC Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
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-09Fix target binary in reserve testsEric B Munson
These three wrappers all pointed at the quota test. This patch updates the wrappers to run the appropriate tests. 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-10-16Fix for bitrot in linkhuge_nofdDavid Gibson
The linkhuge_nofd testcase no longer tests what it's supposed to - that the elflink code will correctly fall back to normal pages if hugepages are not available. The testcase checked this path by overriding the hugetlbfs_unlinked_fd() function with one that always fails. However newer revisions of the elflink code don't use the hugetlbfs_unlinked_fd() function, they use the lower level hugetlbfs_unlinked_fd_for_size(). This patch overrides the correct function and make the testcase do what it's supposed to. Currently the test is effectively a duplicate of the main linkhuge test. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-08-24Suppress ld.hugetlbfs warnings when building testsuiteDavid Gibson
Current versions of the ld.hugetlbfs wrapper script rightly warn if you use the old, broken linker-script based method of building a hugepage binary. However, we still have to build things with this mode to test them. It's kind of nasty having a dozen or so warnings spewing out on a perfectly full and correct build of the testsuite. Therefore, this patch provides an environment variable to suppress those warnings, and uses it from the testsuite makefile to get rid of them in this case. Signed-off-by: David Gibson <dwg@au1.ibm.com> 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-24Correctly clean shmoverride_linked.cDavid Gibson
shmoverride_linked.c is auto-generated as a symlink during make, but is not removed during a "make clean". This corrects the error. Signed-off-by: David Gibson <dwg@au1.ibm.com> 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-07-21Force --no-as-needed linker optionThomas Renninger
Force --no-as-needed linker option Things won't link with --as-needed linker option. Having --as-needed be set in a build environment can give you some headache to find out why it links the one, but not the other way. Signed-off-by: Thomas Renninger <trenn@suse.de> 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-27Move shm segment to 2GB markEric B Munson
Currently the 32bit test fails on ppc64 because ld.so is mapped in at 1GB. This patch moves the shm segment address to avoid the collision. 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-18Update the fail message for readahead, madvise, and fadvise testsEric B Munson
This patch changes the failure message given by the readahead, fadvise, and madvise tests if the kernel is older than 2.6.30 to make it clear that the test failure is assumed. Until the fix for these tests is in kernel they will be skipped because they can hang the kernel. Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
2009-05-15Record what commit fixes the kernelregressions for readahead and the advise ↵Mel Gorman
tests The upstream kernel now has one fix that covers the readahead, fadvise and madvise bugs. Record what commit fixes the problem in the test in case they need to be found for backporting later. 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>