kernel/linux.git/tools/testing/selftests/mm, branch v6.18.48

selftests/mm: fix potential wild pointer access of getline due to missing init

2026-08-09T18:25:18+00:00

commit 9f1d75a4ce04095afdb63d8e540092ff8151dacf upstream. This is another occurrence of using getline where the code assumes that getline allocates memory to store the line, but the pointer passed to it is uninitialized and potentially a non-null pointer. This violates the Open Group Spec[1] and caused a segfault in a similar situation in selftest/clone3/clone3_set_tid. Fix it by initializing the line pointer to NULL. The issue has been found by simply grepping through the selftest code after running into the issue in clone3_set_tid. Whether it segfaults in its current state is unknown to me. But it's good to be addressed due to defensive reasons. Link: https://lore.kernel.org/20260722130246.2135563-3-christian.gellermann@codasip.com Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/getline.html [1] Fixes: 26b4224d9961 ("selftests: expanding more mlock selftest") Signed-off-by: Chris Gellermann Acked-by: David Hildenbrand (arm) Reviewed-by: Lorenzo Stoakes Cc: Christian Brauner Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

selftests/mm: fix exclusive_cow test fork() handling

2026-07-24T14:16:34+00:00

[ Upstream commit cea5702144615878600d3a39b5d8b3cc34719012 ] The test ignores the return value of fork(), so both the parent and the (newly created) child run the COW verification loops and then call hmm_buffer_free() before returning into the kselftest harness, which _exit()s each side. This duplicated teardown sequence has been observed to manifest as a SIGSEGV in the test child, e.g.: hmm-tests[360141]: segfault (11) at 0 nip 10006964 lr 1000ac3c code 1 in hmm-tests[6964,10000000+30000] Fix this by adopting the same fork()-then-wait pattern already used by the nearby anon_write_child / anon_write_child_shared tests in this file: the child performs the COW verification and then _exit(0)s so it does not run the test teardown, while the parent independently verifies COW, waits for the child, and only then frees the buffer. Link: https://lore.kernel.org/20260611034102.1030738-4-aboorvad@linux.ibm.com Fixes: b659baea75469 ("mm: selftests for exclusive device memory") Signed-off-by: Aboorva Devarajan Cc: Alex Sierra Cc: Alistair Popple Cc: Balbir Singh Cc: David Hildenbrand Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Ralph Campbell Cc: Sayali Patil Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

selftests/mm: allow PUD-level entries in compound testcase of hmm tests

2026-07-24T14:16:34+00:00

[ Upstream commit 224ed0e019b122d08580362abe57574a78f2b5fa ] Patch series "selftests/mm: assorted fixes for hmm-tests", v3. This series fixes a few issues in hmm-tests that show up when page-size and huge-page configuration differ from the hardcoded assumptions the tests were written for (PMD/THP sizing, default hugepage size, and related cases). It also includes a fix to exclusive_cow: the test ignored the return value of fork(), so both parent and child ran the same teardown path. This patch (of 3): The HMM compound testcase currently assumes only PMD-level mappings and fails on systems where default_hugepagesz=1G is set, because the region is then reported by the device at PUD level. Determine the mapping level (PMD or PUD) the device reports for the first page of the range and require every page to match that level exactly via ASSERT_EQ(). This accepts PUD-level mappings while preserving the expected/observed protection values printed on failure, and rejects a fragmented mapping that mixes PMD- and PUD-level entries within the same range (which a per-page OR check would have let pass). Link: https://lore.kernel.org/20260611034102.1030738-1-aboorvad@linux.ibm.com Link: https://lore.kernel.org/20260611034102.1030738-2-aboorvad@linux.ibm.com Fixes: e478425bec93 ("mm/hmm: add tests for hmm_pfn_to_map_order()") Signed-off-by: Sayali Patil Co-developed-by: Aboorva Devarajan Signed-off-by: Aboorva Devarajan Cc: Alex Sierra Cc: Alistair Popple Cc: Balbir Singh Cc: David Hildenbrand Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Ralph Campbell Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

selftests/mm: clarify alternate unmapping in compaction_test

2026-07-24T14:16:34+00:00

[ Upstream commit 69ba1d76d93ab818245333cf400928477ba72053 ] Add a comment explaining that every other entry in the list is unmapped to intentionally create fragmentation with locked pages before invoking check_compaction(). Link: https://lore.kernel.org/da5e0a8d5152e54152c0d2f456aac2fac35af291.1779296493.git.sayalip@linux.ibm.com Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory") Signed-off-by: Sayali Patil Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero

2026-07-24T14:16:34+00:00

[ Upstream commit f3bd00507f226a419125df6064632bcbd47d8e70 ] uffd-stress currently fails when the computed nr_pages_per_cpu evaluates to zero: nr_pages_per_cpu = bytes / page_size / nr_parallel This can occur on systems with large hugepage sizes (e.g. 1GB) and a high number of CPUs, where the total allocated memory is sufficient overall but not enough to provide at least one page per cpu. In such cases, the failure is due to insufficient test resources rather than incorrect kernel behaviour. Update the test to treat this condition as a test skip instead of reporting an error. [sayalip@linux.ibm.com: use ksft_exit_skip() instead of KSFT_SKIP] Link: https://lore.kernel.org/88202b56-1dc5-43e2-9d1f-a0823a9531f0@linux.ibm.com Link: https://lore.kernel.org/0707e9a0f1b3dd904c4a069b91db317f9c160faa.1779296493.git.sayalip@linux.ibm.com Fixes: db0f1c138f18 ("selftests/mm: print some details when uffd-stress gets bad params") Signed-off-by: Sayali Patil Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Tested-by: Venkat Rao Bagalkote Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap

2026-07-24T14:16:34+00:00

[ Upstream commit f20ca8972e83f111c4300c60d74314568c8964bc ] The hugetlb-mremap selftest reserves the destination address using a anonymous base-page mapping before calling mremap() with MREMAP_FIXED, while the source region is hugetlb-backed. When remapping a hugetlb mapping into a base-page VMA may fail with: mremap: Device or resource busy This is observed on powerpc hash MMU systems where slice constraints and page size incompatibilities prevent the remap. Ensure the destination region is created using MAP_HUGETLB so that both source and destination VMAs are hugetlb-backed and compatible. Update the FLAGS macro to include MAP_HUGETLB | MAP_SHARED so that both mappings are hugetlb-backed and compatible. Also use the macro for the mmap() calls to avoid repeating the flag combination. This ensures the test reliably exercises hugetlb mremap instead of failing due to VMA type mismatch. Link: https://lore.kernel.org/367644df45c65098f23e3945c6a80f4b8a8964a6.1779296493.git.sayalip@linux.ibm.com Fixes: 12b613206474 ("mm, hugepages: add hugetlb vma mremap() test") Signed-off-by: Sayali Patil Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

selftest/mm: register existing mapping with userfaultfd in hugetlb-mremap

2026-07-24T14:16:34+00:00

[ Upstream commit 1df31d5ef58dc6bdf0f2a8b809152d835c60b28e ] Previously, register_region_with_uffd() created a new anonymous mapping and overwrote the address supplied by the caller before registering the range with userfaultfd. As a result, userfaultfd was applied to an unrelated anonymous mapping instead of the hugetlb region used by the test. Remove the extra mmap() and register the caller-provided address range directly using UFFDIO_REGISTER_MODE_MISSING, so that faults are generated for the hugetlb mapping used by the test. This ensures userfaultfd operates on the actual hugetlb test region and validates the expected fault handling. Before patch: running ./hugetlb-mremap ------------------------- TAP version 13 1..1 Map haddr: Returned address is 0x7eaa40000000 Map daddr: Returned address is 0x7daa40000000 Map vaddr: Returned address is 0x7faa40000000 Address returned by mmap() = 0x7fff9d000000 Mremap: Returned address is 0x7faa40000000 First hex is 0 First hex is 3020100 ok 1 Read same data Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] ok 1 hugetlb-mremap After patch: running ./hugetb-mremap ------------------------- TAP version 13 1..1 Map haddr: Returned address is 0x7eaa40000000 Map daddr: Returned address is 0x7daa40000000 Map vaddr: Returned address is 0x7faa40000000 Registered memory at address 0x7eaa40000000 with userfaultfd Mremap: Returned address is 0x7faa40000000 First hex is 0 First hex is 3020100 ok 1 Read same data Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] ok 1 hugetlb-mremap Link: https://lore.kernel.org/13845da872ed174316173e8996dbb5f181994017.1779296493.git.sayalip@linux.ibm.com Fixes: 12b613206474 ("mm, hugepages: add hugetlb vma mremap() test") Signed-off-by: Sayali Patil Acked-by: David Hildenbrand (Arm) Tested-by: Venkat Rao Bagalkote Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

selftests/mm: free dynamically allocated PMD-sized buffers in split_huge_page_test

2026-07-24T14:16:34+00:00

[ Upstream commit e5d3e1422e92d54e28e81fad8bfc7c1ecb41a353 ] Dynamically allocated buffers of PMD size for file-backed THP operations (file_buf1 and file_buf2) were not freed on the success path and some failure paths. Since the function is called repeatedly in a loop for each split order, this can cause significant memory leaks. On architectures with large PMD sizes, repeated leaks could exhaust system memory and trigger the OOM killer during test execution. Ensure all allocated buffers are freed to maintain stable repeated test runs. Link: https://lore.kernel.org/060c673b376bbeeed2b1fb1d48a825e846654191.1779296493.git.sayalip@linux.ibm.com Fixes: 035a112e5fd5 ("selftests/mm: make file-backed THP split work by writing PMD size data") Signed-off-by: Sayali Patil Reviewed-by: Zi Yan Tested-by: Venkat Rao Bagalkote Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

selftests/mm: size tmpfs according to PMD page size in split_huge_page_test

2026-07-24T14:16:34+00:00

[ Upstream commit a2dde8a065d5c8d63b53b1c8f035017e4aeac0c2 ] The split_file_backed_thp() test mounts a tmpfs with a fixed size of "4m". This works on systems with smaller PMD page sizes, but fails on configurations where the PMD huge page size is larger (e.g. 16MB). On such systems, the fixed 4MB tmpfs is insufficient to allocate even a single PMD-sized THP, causing the test to fail. Fix this by sizing the tmpfs dynamically based on the runtime pmd_pagesize, allocating space for two PMD-sized pages. Before patch: running ./split_huge_page_test /tmp/xfs_dir_YTrI5E -------------------------------------------------- TAP version 13 1..55 ok 1 Split zero filled huge pages successful ok 2 Split huge pages to order 0 successful ok 3 Split huge pages to order 2 successful ok 4 Split huge pages to order 3 successful ok 5 Split huge pages to order 4 successful ok 6 Split huge pages to order 5 successful ok 7 Split huge pages to order 6 successful ok 8 Split huge pages to order 7 successful ok 9 Split PTE-mapped huge pages successful Please enable pr_debug in split_huge_pages_in_file() for more info. Failed to write data to testing file: Success (0) Bail out! Error occurred Planned tests != run tests (55 != 9) Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0 [FAIL] After patch: running ./split_huge_page_test /tmp/xfs_dir_bMvj6o -------------------------------------------------- TAP version 13 1..55 ok 1 Split zero filled huge pages successful ok 2 Split huge pages to order 0 successful ok 3 Split huge pages to order 2 successful ok 4 Split huge pages to order 3 successful ok 5 Split huge pages to order 4 successful ok 6 Split huge pages to order 5 successful ok 7 Split huge pages to order 6 successful ok 8 Split huge pages to order 7 successful ok 9 Split PTE-mapped huge pages successful Please enable pr_debug in split_huge_pages_in_file() for more info. Please check dmesg for more information ok 10 File-backed THP split to order 0 test done Please enable pr_debug in split_huge_pages_in_file() for more info. Please check dmesg for more information ok 11 File-backed THP split to order 1 test done Please enable pr_debug in split_huge_pages_in_file() for more info. Please check dmesg for more information ok 12 File-backed THP split to order 2 test done ... ok 55 Split PMD-mapped pagecache folio to order 7 at in-folio offset 128 passed Totals: pass:55 fail:0 xfail:0 xpass:0 skip:0 error:0 [PASS] ok 1 split_huge_page_test /tmp/xfs_dir_bMvj6o Link: https://lore.kernel.org/33e1bc10753fe82d1217613d8cd496020778cf2b.1779296493.git.sayalip@linux.ibm.com Fixes: fbe37501b252 ("mm: huge_memory: debugfs for file-backed THP split") Signed-off-by: Sayali Patil Reviewed-by: Zi Yan Reviewed-by: David Hildenbrand (Arm) Tested-by: Venkat Rao Bagalkote Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

selftests/mm: fix cgroup task placement and drop memory.current checks in hugetlb_reparenting_test.sh

2026-07-24T14:16:33+00:00

[ Upstream commit 7bbdc459527075c4d0b96133de25a53822397af0 ] The test currently moves the calling shell ($$) into the target cgroup before executing write_to_hugetlbfs. This results in the shell and any intermediate allocations being charged to the cgroup, introducing noise and nondeterminism in accounting. It also requires moving the shell back to the root cgroup after execution. Spawn a helper process that joins the target cgroup and exec()'s write_to_hugetlbfs. This ensures that only the workload is accounted to the cgroup and avoids unintended charging from the shell. The test currently validates both hugetlb usage and memory.current. However, memory.current includes internal memcg allocations and per-CPU batched accounting (MEMCG_CHARGE_BATCH), which are not synchronized and can vary across systems, leading to non-deterministic results. Since hugetlb memory is accounted via hugetlb..current, memory.current is not a reliable indicator here. Drop memory.current checks and rely only on hugetlb controller statistics for stable and accurate validation. Link: https://lore.kernel.org/fb57491ba83cb0a499c72922e1579b61bee514db.1779296493.git.sayalip@linux.ibm.com Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: Sayali Patil Cc: David Hildenbrand (Arm) Cc: Dev Jain Cc: Liam Howlett Cc: Miaohe Lin Cc: Michal Hocko Cc: Oscar Salvador Cc: "Ritesh Harjani (IBM)" Cc: Shuah Khan Cc: Venkat Rao Bagalkote Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin