Re: [PATCH v5 2/3] kselftest: mm: replace usage of /proc/self/smaps for check_huge_xxx() helper
From: "David Hildenbrand (Arm)" <david@kernel.org>
Date: 2026-09-10 11:00:04
Also in:
linux-kselftest, lkml
On 9/10/26 12:54, Yeoreum Yun wrote:
quoted
On 9/7/26 10:19, Yeoreum Yun wrote:quoted
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(). Furthermore, a subsequent madvise(MADV_HUGEPAGE) call does not split the VMA because the flag is already set. This causes split_huge_page_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. 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. Suggested-by: David Hildenbrand (Arm) <david@kernel.org> Suggested-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Tested-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Yeoreum Yun <redacted> --- tools/testing/selftests/mm/vm_util.c | 145 ++++++++++++++++++++++------------- tools/testing/selftests/mm/vm_util.h | 1 + 2 files changed, 92 insertions(+), 54 deletions(-)diff --git a/tools/testing/selftests/mm/vm_util.c b/tools/testing/selftests/mm/vm_util.c index 4821a3563036..dc62ce84e143 100644[...]quoted
- if (hpage_size == pmd_pagesize) - return __check_pmd_huge(addr, "AnonHugePages: ", nr_hpages, hpage_size); +static bool check_huge_type(uint64_t categories, uint64_t kpageflags, + enum check_huge_type type) +{ + const bool file = categories & PAGE_IS_FILE; + const bool swapbacked = kpageflags & KPF_SWAPBACKED; + + switch (type) { + case CHECK_HUGE_ANON: + return !file; + case CHECK_HUGE_FILE: + return file && !swapbacked; + case CHECK_HUGE_SHMEM: + return file & swapbacked; + }Why do we even need CHECK_HUGE_SHMEM? That's really just a legacy thing for using smaps to identify huge pages. It's sufficient to identify CHECK_HUGE_FILE if you know that you have shmem mapping. You will not arbitrarily have non-shmem folios in a shmem mapping :)Agree. but there seems the case where discern whethr the mapping is with regular file or shmem like tmpfs -- khugepaged test where using __shmem_ops. So I think it would be better to keep this as-is.
Let's not add or maintain unnecessary complexity. hmem_check_huge can really just become check_huge_file. Even file_check_huge can just be simplified. There must be a pretty good reason why we'd want to keep this. -- Cheers, David