kernel/linux.git/tools/testing/selftests/mm/virtual_address_range.c, branch v6.19.12

selftests: complete kselftest include centralization

2025-11-27T22:24:31+00:00

This follow-up patch completes centralization of kselftest.h and ksefltest_harness.h includes in remaining seltests files, replacing all relative paths with a non-relative paths using shared -I include path in lib.mk Tested with gcc-13.3 and clang-18.1, and cross-compiled successfully on riscv, arm64, x86_64 and powerpc arch. [reddybalavignesh9979@gmail.com: add selftests include path for kselftest.h] Link: https://lkml.kernel.org/r/20251017090201.317521-1-reddybalavignesh9979@gmail.com Link: https://lkml.kernel.org/r/20251016104409.68985-1-reddybalavignesh9979@gmail.com Signed-off-by: Bala-Vignesh-Reddy Suggested-by: Andrew Morton Link: https://lore.kernel.org/lkml/20250820143954.33d95635e504e94df01930d0@linux-foundation.org/ Reviewed-by: Wei Yang Cc: David Hildenbrand Cc: David S. Miller Cc: Eric Dumazet Cc: Günther Noack Cc: Jakub Kacinski Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mickael Salaun Cc: Ming Lei Cc: Paolo Abeni Cc: Shuah Khan Cc: Simon Horman Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

selftests/mm: add support to test 4PB VA on PPC64

2025-09-13T23:55:03+00:00

PowerPC64 supports a 4PB virtual address space, but this test was previously limited to 512TB. This patch extends the coverage up to the full 4PB VA range on PowerPC64. Memory from 0 to 128TB is allocated without an address hint, while allocations from 128TB to 4PB use a hint address. Link: https://lkml.kernel.org/r/20250816040113.760010-3-aboorvad@linux.ibm.com Co-developed-by: Aboorva Devarajan Signed-off-by: Aboorva Devarajan Signed-off-by: Donet Tom Reviewed-by: Dev Jain Acked-by: David Hildenbrand Reviewed-by: Zi Yan Reviewed-by: Wei Yang Cc: Baolin Wang Cc: Barry Song Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mariano Pache Cc: "Ritesh Harjani (IBM)" Cc: Ryan Roberts Cc: Shuah Khan Signed-off-by: Andrew Morton

mm/selftests: fix incorrect pointer being passed to mark_range()

2025-09-13T23:55:03+00:00

Patch series "selftests/mm: Fix false positives and skip unsupported tests", v4. This patch series addresses false positives in the generic mm selftests and skips tests that cannot run correctly due to missing features or system limitations. This patch (of 7): In main(), the high address is stored in hptr, but for mark_range(), the address passed is ptr, not hptr. Fixed this by changing ptr[i] to hptr[i] in mark_range() function call. Link: https://lkml.kernel.org/r/20250816040113.760010-1-aboorvad@linux.ibm.com Link: https://lkml.kernel.org/r/20250816040113.760010-2-aboorvad@linux.ibm.com Fixes: b2a79f62133a ("selftests/mm: virtual_address_range: unmap chunks after validation") Co-developed-by: Aboorva Devarajan Signed-off-by: Aboorva Devarajan Signed-off-by: Donet Tom Reviewed-by: Dev Jain Acked-by: David Hildenbrand Reviewed-by: Zi Yan Reviewed-by: Wei Yang Cc: Baolin Wang Cc: Barry Song Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mariano Pache Cc: "Ritesh Harjani (IBM)" Cc: Ryan Roberts Cc: Shuah Khan Signed-off-by: Andrew Morton

selftests/mm: fix validate_addr() helper

2025-06-25T22:55:04+00:00

validate_addr() checks whether the address returned by mmap() lies in the low or high VA space, according to whether a high addr hint was passed or not. The fix commit mentioned below changed the code in such a way that this function will always return failure when passed high_addr == 1; addr will be >= HIGH_ADDR_MARK always, we will fall down to "if (addr > HIGH_ADDR_MARK)" and return failure. Fix this. Link: https://lkml.kernel.org/r/20250620111150.50344-1-dev.jain@arm.com Fixes: d1d86ce28d0f ("selftests/mm: virtual_address_range: conform to TAP format output") Signed-off-by: Dev Jain Reviewed-by: Donet Tom Acked-by: David Hildenbrand Cc: Anshuman Khandual Cc: Lorenzo Stoakes Cc: Ryan Roberts Cc: Shuah Khan Signed-off-by: Andrew Morton

selftests/mm: virtual_address_range: avoid reading from VM_IO mappings

2025-01-26T04:22:44+00:00

The virtual_address_range selftest reads from the start of each mapping listed in /proc/self/maps. However not all mappings are valid to be arbitrarily accessed. For example the vvar data used for virtual clocks on x86 [vvar_vclock] can only be accessed if 1) the kernel configuration enables virtual clocks and 2) the hypervisor provided the data for it. Only the VDSO itself has the necessary information to know this. Since commit e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping") the virtual clock data was split out into its own mapping, leading to EFAULT from read() during the validation. Check for the VM_IO flag as a proxy. It is present for the VVAR mappings and MMIO ranges can be dangerous to access arbitrarily. Link: https://lkml.kernel.org/r/20250114-virtual_address_range-tests-v4-4-6fd7269934a5@linutronix.de Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202412271148.2656e485-lkp@intel.com Fixes: e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping") Fixes: 010409649885 ("selftests/mm: confirm VA exhaustion without reliance on correctness of mmap()") Signed-off-by: Thomas Weißschuh Suggested-by: David Hildenbrand Link: https://lore.kernel.org/lkml/e97c2a5d-c815-4936-a767-ac42a3220a90@redhat.com/ Acked-by: David Hildenbrand Cc: Anshuman Khandual Cc: Dev Jain Cc: Shuah Khan (Samsung OSG) Cc: Thomas Gleixner Signed-off-by: Andrew Morton

selftests/mm: virtual_address_range: unmap chunks after validation

2025-01-26T04:22:44+00:00

For each accessed chunk a PTE is created. More than 1GiB of PTEs is used in this way. Remove each PTE after validating a chunk to reduce peak memory usage. It is important to only unmap memory that previously mmap()ed, as unmapping other mappings like the stack, heap or executable mappings will crash the process. The mappings read from /proc/self/maps and the return values from mmap() don't allow a simple correlation due to merging and no guaranteed order. To correlate the pointers and mappings use prctl(PR_SET_VMA_ANON_NAME). While it introduces a test dependency, other alternatives would introduce runtime or development overhead. Link: https://lkml.kernel.org/r/20250114-virtual_address_range-tests-v4-2-6fd7269934a5@linutronix.de Fixes: 010409649885 ("selftests/mm: confirm VA exhaustion without reliance on correctness of mmap()") Signed-off-by: Thomas Weißschuh Acked-by: David Hildenbrand Cc: Anshuman Khandual Cc: Dev Jain Cc: kernel test robot Cc: Shuah Khan (Samsung OSG) Cc: Thomas Gleixner Signed-off-by: Andrew Morton

selftests/mm: virtual_address_range: mmap() without PROT_WRITE

2025-01-26T04:22:44+00:00

Patch series "selftests/mm: virtual_address_range: Reduce memory", v4. The selftest started failing since commit e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping") was merged. While debugging I stumbled upon some memory usage optimizations. With these test now runs on a VM with only 60MiB of memory. This patch (of 4): When mapping a larger chunk than physical memory is available with PROT_WRITE and overcommit is disabled, the mapping will fail. This will prevent the test from running on systems with less then ~1GiB of memory and triggering an inscrutinable test failure. As the mappings are never written to anyways, the flag can be removed. Link: https://lkml.kernel.org/r/20250114-virtual_address_range-tests-v4-0-6fd7269934a5@linutronix.de Link: https://lkml.kernel.org/r/20250114-virtual_address_range-tests-v4-1-6fd7269934a5@linutronix.de Fixes: 4e5ce33ceb32 ("selftests/vm: add a test for virtual address range mapping") Signed-off-by: Thomas Weißschuh Acked-by: David Hildenbrand Acked-by: Dev Jain Cc: Thomas Gleixner Cc: Anshuman Khandual Cc: Shuah Khan (Samsung OSG) Cc: kernel test robot Signed-off-by: Andrew Morton

selftest/mm: fix typo in virtual_address_range

2024-11-11T21:09:41+00:00

The function name should be *hint* address, so correct it. Link: https://lkml.kernel.org/r/20241008094141.549248-4-zhangchunyan@iscas.ac.cn Signed-off-by: Chunyan Zhang Reviewed-by: Charlie Jenkins Acked-by: Palmer Dabbelt Cc: Alexandre Ghiti Cc: Paul Walmsley Cc: Shuah Khan Signed-off-by: Andrew Morton

selftests/mm: confirm VA exhaustion without reliance on correctness of mmap()

2024-04-26T03:56:01+00:00

Currently, VA exhaustion is being checked by passing a hint to mmap() and expecting it to fail. While populating the lower VA space, mmap() fails because we have exhausted the space. Then, in validate_lower_address_hint(), because mmap() fails, we confirm that we have indeed exhausted the space. There is a circular logic involved here. Assume that there is a bug in mmap(), also assume that it exists independent of whether you pass a hint address or not; that for some reason it is not able to find a 1GB chunk. My idea is to assert the exhaustion against some other method. This patch makes a stricter test by successful write() calls from /proc/self/maps to a dump file, confirming that a free chunk is indeed not available. [dev.jain@arm.com: replace SZ_1GB with MAP_CHUNK_SIZE, tidy-up] Link: https://lkml.kernel.org/r/20240325042653.867055-1-dev.jain@arm.com Link: https://lkml.kernel.org/r/20240321103522.516097-1-dev.jain@arm.com Signed-off-by: Dev Jain Cc: Anshuman Khandual Cc: Shuah Khan Signed-off-by: Andrew Morton

selftests/mm: virtual_address_range: Switch to ksft_exit_fail_msg

2024-04-26T03:55:43+00:00

mmap() must not succeed in validate_lower_address_hint(), for if it does, it is a bug in mmap() itself. Reflect this behaviour with ksft_exit_fail_msg(). While at it, do some formatting changes. Link: https://lkml.kernel.org/r/20240314122250.68534-1-dev.jain@arm.com Signed-off-by: Dev Jain Reviewed-by: Muhammad Usama Anjum Cc: Anshuman Khandual Cc: Shuah Khan Signed-off-by: Andrew Morton