From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65F2B42E426 for ; Thu, 24 Sep 2026 20:06:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790280401; cv=none; b=lleEuMrmH+U/cKgk5CmIl2fpIP7VU2/9mX8aRwt+uBpFgcuRv0VduuKxpwUMujKh3mJRHSLnz4gvNA40nesCzhnHHcHtMzlDKJUapmV6srBfuIhr3mi+l+enIz2nKcFGPOJHmxJMXFgsJSQLsAct3JbNi/7OSZm3iFS94ZlnNeY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790280401; c=relaxed/simple; bh=tm645vNNu5pBn3pBt6Yvd/56zmwUpDchrZAUPtNNDNQ=; h=Date:To:From:Subject:Message-Id; b=WsiFd8O3zlRDaaTe9QCYeUjwCpkPijTm2QLdYcu/8hZ0fNJY2xSPzmVkMVFvMKkx2EiEGZQpagKPOJD7apK2pp4gLMW0jrSZl2pbtOUqYUXDxzFPL1iv8TQ4XmKS7qCAeJ5FDOelVpEGKxwlMA5y+BsgM/n3WLOkkjz9LuBM6rE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=hxK7fVDB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="hxK7fVDB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E632D1F000FF; Thu, 24 Sep 2026 20:06:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1790280400; bh=0hm+zb6TamzpUcJJqwXW4jgLspReofBHa85j4ML1KkY=; h=Date:To:From:Subject; b=hxK7fVDBpOZiC/yWxonG8gZf2QpUtxht+jIMf6x5AMRIap2/fK/J8MB2HZDByv9b/ IO9N6mpfaQKKv8cTibxluYPs3CUy3buaBsqPhkNrXU3ByeFmB/lDcXNRJwCz68ABYb 6BtnZLJQYvuJ6HlkoJdvAMOlxiEQL5188NCWXbVg= Date: Thu, 24 Sep 2026 13:06:39 -0700 To: mm-commits@vger.kernel.org,ziy@nvidia.com,vbabka@kernel.org,usama.arif@linux.dev,surenb@google.com,shuah@kernel.org,ryan.roberts@arm.com,rppt@kernel.org,nico.pache@linux.dev,mhocko@suse.com,ljs@kernel.org,liam@infradead.org,lance.yang@linux.dev,kevin.brodsky@arm.com,dev.jain@arm.com,david@kernel.org,baolin.wang@linux.alibaba.com,baohua@kernel.org,yeoreum.yun@arm.com,akpm@linux-foundation.org From: Andrew Morton Subject: + kselftest-mm-prevent-random-failure-of-huge-page-split-for-khugepaged.patch added to mm-new branch Message-Id: <20260924200639.E632D1F000FF@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: kselftest: mm: prevent random failure of huge page split for khugepaged has been added to the -mm mm-new branch. Its filename is kselftest-mm-prevent-random-failure-of-huge-page-split-for-khugepaged.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kselftest-mm-prevent-random-failure-of-huge-page-split-for-khugepaged.patch This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. The mm-new branch of mm.git is not included in linux-next If a few days of testing in mm-new is successful, the patch will me moved into mm.git's mm-unstable branch, which is included in linux-next Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Yeoreum Yun Subject: kselftest: mm: prevent random failure of huge page split for khugepaged Date: Thu, 24 Sep 2026 20:11:16 +0100 Patch series "kselftest: mm: fix some failure of split_huge_page_test", v8. split_huge_page_test can fail for the following reasons: 1. During the test, khugepaged may collapse previously split pages again, causing intermittent failures. 2. Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations made by memalign(). The underlying VMA may start at a different address from the aligned address returned by memalign(). Moreover, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because it already has the same advice. This causes the test to fail because the check_huge_xxx() helpers incorrectly require the address returned by memalign() to match the VMA start address reported in /proc/self/smaps. Address these issues by applying MADV_NOHUGEPAGE after faulting in the huge page, preventing khugepaged from collapsing it again, and instead of relying on /proc/self/smaps, use /proc/self/pagemap and /proc/kpageflags to detect huge-page mappings and large folios: 1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of using check_large_folios(), since only the mapping type matters. This identifies PMD-mapped huge pages. 2. Otherwise, use check_large_folios() to detect large folios. This covers mTHP cases. 3. Check the folio flags according to the type of huge page. Since check_huge_shmem() was required to distinguish shmem huge pages because /proc/self/smaps reports them using a dedicated “ShmemPmdMapped” entry, as opposed to “FilePmdMapped” for file-backed huge pages. Now that /proc/self/smaps is no longer used to detect huge pages and /proc/kpageflags is used instead, it is sufficient to distinguish between file-backed and anonymous pages since the ShmemPmdMapped is also kind of file-backed. Therefore, remove check_huge_shmem() and use check_huge_file() instead. This patch (of 4): There're some random failure for split_huge_page_test when khugepaged collapses pages into pmd again which had split by the test. Prevent the khugepaged's collapses for split page by setting the mapped pmd-huge-page with MADV_NOHUGEPAGE before split. Link: https://lore.kernel.org/20260924-fix_split-v8-0-cba7359d882a@arm.com Link: https://lore.kernel.org/20260924-fix_split-v8-1-cba7359d882a@arm.com Signed-off-by: Yeoreum Yun Signed-off-by: Andrew Morton Suggested-by: Kevin Brodsky Suggested-by: Lorenzo Stoakes (ARM) Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Liam R. Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Dev Jain Cc: Barry Song Cc: Lance Yang Cc: Usama Arif Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Shuah Khan --- tools/testing/selftests/mm/split_huge_page_test.c | 19 ++++++++++++ 1 file changed, 19 insertions(+) --- a/tools/testing/selftests/mm/split_huge_page_test.c~kselftest-mm-prevent-random-failure-of-huge-page-split-for-khugepaged +++ a/tools/testing/selftests/mm/split_huge_page_test.c @@ -108,6 +108,18 @@ static char *allocate_zero_filled_hugepa return result; } +static void disable_khugepaged(void *addr, size_t len) +{ + /* + * Disables khugepaged from collapsing THPs in range, existing THP + * pages remain. + */ + if (!madvise(addr, len, MADV_NOHUGEPAGE)) + return; + + ksft_exit_fail_msg("MADV_NOHUGEPAGE failed, err=%d\n", errno); +} + static void verify_rss_anon_split_huge_page_all_zeroes(char *one_page, int nr_hpages, size_t len) { unsigned long rss_anon_before, rss_anon_after; @@ -120,6 +132,8 @@ static void verify_rss_anon_split_huge_p if (!rss_anon_before) ksft_exit_fail_msg("No RssAnon is allocated before split\n"); + disable_khugepaged(one_page, len); + /* split all THPs */ write_debugfs(PID_FMT, getpid(), (uint64_t)one_page, (uint64_t)one_page + len, 0); @@ -167,6 +181,8 @@ static void split_pmd_thp_to_order(int o if (!check_huge_anon(one_page, 4 * pmd_pagesize, 4, pmd_pagesize)) ksft_exit_fail_msg("No THP is allocated\n"); + disable_khugepaged(one_page, len); + /* split all THPs */ write_debugfs(PID_FMT, getpid(), (uint64_t)one_page, (uint64_t)one_page + len, order); @@ -215,6 +231,8 @@ static void split_pte_mapped_thp(void) goto out; } + disable_khugepaged(thp_area, thp_area_size); + /* * To challenge spitting code, we will mremap a single page of each * THP (page[i] of thp[i]) in the thp_area into page_area. This will @@ -482,6 +500,7 @@ static int create_pagecache_thp_and_fd(c ksft_test_result_skip("Pagecache folio split skipped\n"); return -2; } + disable_khugepaged(*addr, fd_size); return 0; err_out_close: close(*fd); _ Patches currently in -mm which might be from yeoreum.yun@arm.com are kselftest-mm-fix-potential-failure-for-merged-vma-in-guard-regions.patch kselftest-mm-remove-exclusion-of-building-soft-dirty-test-in-arm64.patch kselftest-mm-return-fail-when-child-test-result-is-fail-in-khugepaged.patch kselftest-mm-fix-intermittent-failure-khugepaged-test.patch kselftest-mm-prevent-random-failure-of-huge-page-split-for-khugepaged.patch kselftest-mm-replace-usage-of-proc-self-smaps-for-__check_pmd_huge.patch kselftest-mm-integrate-huge-page-checks.patch kselftest-mm-remove-check_huge_shmem.patch