kernel.git/tools/testing/selftests/mm/run_vmtests.sh, branch master

selftests/mm: add memory failure anonymous page test

2026-02-12T23:43:01Z

Patch series "selftests/mm: add memory failure selftests", v4. Introduce selftests to validate the functionality of memory failure. These tests help ensure that memory failure handling for anonymous pages, pagecaches pages works correctly, including proper SIGBUS delivery to user processes, page isolation, and recovery paths. Currently madvise syscall is used to inject memory failures. And only anonymous pages and pagecaches are tested. More test scenarios, e.g. hugetlb, shmem, thp, will be added. Also more memory failure injecting methods will be supported, e.g. APEI Error INJection, if required. This patch (of 3): This patch adds a new kselftest to validate memory failure handling for anonymous pages. The test performs the following operations: 1. Allocates anonymous pages using mmap(). 2. Injects memory failure via madvise syscall. 3. Verifies expected error handling behavior. 4. Unpoison memory. This test helps ensure that memory failure handling for anonymous pages works correctly, including proper SIGBUS delivery to user processes, page isolation and recovery paths. Link: https://lkml.kernel.org/r/20260206031639.2707102-1-linmiaohe@huawei.com Link: https://lkml.kernel.org/r/20260206031639.2707102-2-linmiaohe@huawei.com Signed-off-by: Miaohe Lin Cc: David Hildenbrand Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mark Brown Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: kernel test robot Signed-off-by: Andrew Morton

selftests/mm: have the harness run each test category separately

2026-01-31T22:22:53Z

At present the mm selftests are integrated into the kselftest harness by having it run run_vmtest.sh and letting it pick it's default set of tests to invoke, rather than by telling the kselftest framework about each test program individually as is more standard. This has some unfortunate interactions with the kselftest harness: - If any of the tests hangs the harness will kill the entire mm selftests run rather than just the individual test, meaning no further tests get run. - The timeout applied by the harness is applied to the whole run rather than an individual test which frequently leads to the suite not being completed in production testing. Deploy a crude but effective mitigation for these issues by telling the kselftest framework to run each of the test categories that run_vmtests.sh has separately. Since kselftest really wants to run test programs this is done by providing a trivial wrapper script for each categorty that invokes run_vmtest.sh, this is not a thing of great elegence but it is clear and simple. Since run_vmtests.sh is doing runtime support detection, scenario enumeration and setup for many of the tests we can't consistently tell the framework about the individual test programs. This has the side effect of reordering the tests, hopefully the testing is not overly sensitive to this. Link: https://lkml.kernel.org/r/20260123-selftests-mm-run-suites-separately-v2-1-3e934edacbfa@kernel.org Signed-off-by: Mark Brown Reviewed-by: Lorenzo Stoakes Cc: David Hildenbrand Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

selftests/mm: remove virtual_address_range test

2026-01-31T22:22:43Z

This self test is asserting internal implementation details and is highly vulnerable to internal kernel changes as a result. It is currently failing locally from at least v6.17, and it seems that it may have been failing for longer in many configurations/hardware as it skips if e.g. CONFIG_ANON_VMA_NAME is not specified. With these skips and the fact that run_vmtests.sh won't run the tests in certain configurations it is likely we have simply missed this test being broken in CI for a long while. I have tried multiple versions of these tests and am unable to find a working bisect as previous versions of the test fail also. The tests are essentially mmap()'ing a series of mappings with no hint and asserting what the get_unmapped_area*() functions will come up with, with seemingly few checks for what other mappings may already be in place. It then appears to be mmap()'ing with a hint, and making a series of similar assertions about the internal implementation details of the hinting logic. Commit 0ef3783d7558 ("selftests/mm: add support to test 4PB VA on PPC64"), commit 3bd6137220bb ("selftests/mm: virtual_address_range: avoid reading from VM_IO mappings"), and especially commit a005145b9c96 ("selftests/mm: virtual_address_range: mmap() without PROT_WRITE") are good examples of the whack-a-mole nature of maintaining this test. The last commit there being particularly pertinent as it was accounting for an internal implementation detail change that really should have no bearing on self-tests, that is commit e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping"). The purpose of the mm self-tests are to assert attributes about the API exposed to users, and to ensure that expectations are met. This test is emphatically not doing this, rather making a series of assumptions about internal implementation details and asserting them. It therefore, sadly, seems that the best course is to remove this test altogether. Link: https://lkml.kernel.org/r/20260116132053.857887-1-lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Acked-by: SeongJae Park Cc: David Hildenbrand Cc: Liam Howlett Cc: Mark Brown Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

selftests/mm: remove arm64 nr_hugepages setup for va_high_addr_switch test

2026-01-21T03:24:52Z

arm64 and x86_64 has the same nr_hugepages requriement for running the va_high_addr_switch test. Since commit d9d957bd7b61 ("selftests/mm: alloc hugepages in va_high_addr_switch test"), the setup can be done in va_high_addr_switch.sh. So remove the duplicated setup. Link: https://lkml.kernel.org/r/20251221040025.3159990-3-chuhu@redhat.com Signed-off-by: Chunyu Hu Reviewed-by: Luiz Capitulino Cc: Luiz Capitulino Cc: "David Hildenbrand (Red Hat)" Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

selftests/mm: gup_tests: option to GUP all pages in a single call

2025-09-21T21:22:33Z

We recently missed detecting an issue during early testing because the default (!all) tests would not trigger it and even when running "all" tests it only would happen sometimes because of races. So let's allow for an easy way to specify "GUP all pages in a single call", extend the test matrix and extend our default (!all) tests. By GUP'ing all pages in a single call, with the default size of 128MiB we'll cover multiple leaf page tables / PMDs on architectures with sane THP sizes. Link: https://lkml.kernel.org/r/20250910093051.1693097-1-david@redhat.com Signed-off-by: David Hildenbrand Cc: Jason Gunthorpe Cc: John Hubbard Cc: Peter Xu Cc: Lorenzo Stoakes Cc: "Liam R. Howlett" Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Shuah Khan Signed-off-by: Andrew Morton

selftests/mm: fix hugepages cleanup too early

2025-09-21T21:22:28Z

Patch series "Fix va_high_addr_switch.sh test failure", v3. These three patches fix the va_high_addr_switch.sh test failure on x86_64. Patch 1 fixes the hugepage setup issue that nr_hugepages is reset too early in run_vmtests.sh and break the later va_high_addr_switch testing. Patch 2 adds hugepage setup in va_high_addr_switch test, so that it can still work if vm_runtests.sh changes the hugepage setup someday. Patch 3 fixes the test failure caused by the hint addr align method change in hugetlb_get_unmapped_area(). This patch (of 3): The nr_hugepgs variable is used to keep the original nr_hugepages at the hugepage setup step at test beginning. After userfaultfd test, a cleaup is executed, both /sys/kernel/mm/hugepages/hugepages-*/nr_hugepages and /proc/sys//vm/nr_hugepages are reset to 'original' value before userfaultfd test starts. Issue here is the value used to restore /proc/sys/vm/nr_hugepages is nr_hugepgs which is the initial value before the vm_runtests.sh runs, not the value before userfaultfd test starts. 'va_high_addr_swith.sh' tests runs after that will possibly see no hugepages available for test, and got EINVAL when mmap(HUGETLB), making the result invalid. And before pkey tests, nr_hugepgs is changed to be used as a temp variable to save nr_hugepages before pkey test, and restore it after pkey tests finish. The original nr_hugepages value is not tracked anymore, so no way to restore it after all tests finish. Add a new variable orig_nr_hugepgs to save the original nr_hugepages, and and restore it to nr_hugepages after all tests finish. And change to use the nr_hugepgs variable to save the /proc/sys/vm/nr_hugeages after hugepage setup, it's also the value before userfaultfd test starts, and the correct value to be restored after userfaultfd finishes. The va_high_addr_switch.sh broken will be resolved. Link: https://lkml.kernel.org/r/20250912013711.3002969-1-chuhu@redhat.com Link: https://lkml.kernel.org/r/20250912013711.3002969-2-chuhu@redhat.com Signed-off-by: Chunyu Hu Acked-by: David Hildenbrand Signed-off-by: Andrew Morton

selftests/mm/uffd-stress: make test operate on less hugetlb memory

2025-09-13T23:55:19Z

Patch series "selftests/mm: uffd-stress fixes", v2. This patchset ensures that the number of hugepages is correctly set in the system so that the uffd-stress test does not fail due to the racy nature of the test. Patch 1 changes the hugepage constraint in the run_vmtests.sh script, whereas patch 2 changes the constraint in the test itself. This patch (of 2): We observed uffd-stress selftest failure on arm64 and intermittent failures on x86 too: running ./uffd-stress hugetlb-private 128 32 bounces: 17, mode: rnd read, ERROR: UFFDIO_COPY error: -12 (errno=12, @uffd-common.c:617) [FAIL] not ok 18 uffd-stress hugetlb-private 128 32 # exit=1 For this particular case, the number of free hugepages from run_vmtests.sh will be 128, and the test will allocate 64 hugepages in the source location. The stress() function will start spawning threads which will operate on the destination location, triggering uffd-operations like UFFDIO_COPY from src to dst, which means that we will require 64 more hugepages for the dst location. Let us observe the locking_thread() function. It will lock the mutex kept at dst, triggering uffd-copy. Suppose that 127 (64 for src and 63 for dst) hugepages have been reserved. In case of BOUNCE_RANDOM, it may happen that two threads trying to lock the mutex at dst, try to do so at the same hugepage number. If one thread succeeds in reserving the last hugepage, then the other thread may fail in alloc_hugetlb_folio(), returning -ENOMEM. I can confirm that this is indeed the case by this hacky patch: :--- a/mm/hugetlb.c ; +++ b/mm/hugetlb.c ; @@ -6929,6 +6929,11 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte, ; ; folio = alloc_hugetlb_folio(dst_vma, dst_addr, false); ; if (IS_ERR(folio)) { ; + pte_t *actual_pte = hugetlb_walk(dst_vma, dst_addr, PMD_SIZE); ; + if (actual_pte) { ; + ret = -EEXIST; ; + goto out; ; + } ; ret = -ENOMEM; ; goto out; ; } This code path gets triggered indicating that the PMD at which one thread is trying to map a hugepage, gets filled by a racing thread. Therefore, instead of using freepgs to compute the amount of memory, use freepgs - (min(32, nr_cpus) - 1), so that the test still has some extra hugepages to use. The adjustment is a function of min(32, nr_cpus) - the value of nr_parallel in the test - because in the worst case, nr_parallel number of threads will try to map a hugepage on the same PMD, one will win the allocation race, and the other nr_parallel - 1 threads will fail, so we need extra nr_parallel - 1 hugepages to satisfy this request. Note that, in case the adjusted value underflows, there is a check for the number of free hugepages in the test itself, which will fail: get_free_hugepages() < bytes / page_size A negative value will be passed on to bytes which is of type size_t, thus the RHS will become a large value and the check will fail, so we are safe. Link: https://lkml.kernel.org/r/20250909061531.57272-1-dev.jain@arm.com Link: https://lkml.kernel.org/r/20250909061531.57272-2-dev.jain@arm.com Signed-off-by: Dev Jain Cc: David Hildenbrand Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mariano Pache Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

selftests/mm: test that rmap behaves as expected

2025-09-13T23:55:13Z

As David suggested, currently we don't have a high level test case to verify the behavior of rmap. This patch introduce the verification on rmap by migration. The general idea is if migrate one shared page between processes, this would be reflected in all related processes. Otherwise, we have problem in rmap. Currently it covers following four scenarios: * anonymous page * shmem page * pagecache page * ksm page Link: https://lkml.kernel.org/r/20250819080047.10063-3-richard.weiyang@gmail.com Signed-off-by: Wei Yang Suggested-by: David Hildenbrand Cc: David Hildenbrand Cc: Lorenzo Stoakes Cc: Rik van Riel Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Harry Yoo Signed-off-by: Andrew Morton

selftests/mm: add process_madvise() tests

2025-08-02T19:06:08Z

Add tests for process_madvise(), focusing on verifying behavior under various conditions including valid usage and error cases. [lianux.mm@gmail.com: v7] Link: https://lkml.kernel.org/r/20250729113109.12272-1-lianux.mm@gmail.com Link: https://lkml.kernel.org/r/20250729113109.12272-1-lianux.mm@gmail.com Link: https://lkml.kernel.org/r/20250721114614.40996-1-lianux.mm@gmail.com Signed-off-by: wang lian Suggested-by: Lorenzo Stoakes Suggested-by: David Hildenbrand Suggested-by: Zi Yan Suggested-by: Mark Brown Acked-by: SeongJae Park Reviewed-by: Zi Yan Tested-by: Zi Yan Cc: Christian Brauner Cc: Jann Horn Cc: Kairui Song Cc: Liam Howlett Cc: Shuah Khan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

selftests: mm: add shmem collapse as a default test item

2025-07-10T05:42:09Z

Currently, we only test anonymous memory collapse by default. We should also add shmem collapse as a default test item to catch issues that could break the test cases. Link: https://lkml.kernel.org/r/a30b1529b399f2e649b5a05c3d352f41a68faeae.1749779183.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Reviewed-by: Dev Jain Tested-by: Dev Jain Acked-by: David Hildenbrand Acked-by: Zi Yan Cc: Barry Song Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mariano Pache Cc: Ryan Roberts Cc: Shuah Khan Signed-off-by: Andrew Morton