Re: [PATCH v5 2/3] kselftest: mm: replace usage of /proc/self/smaps for check_huge_xxx() helper
From: Yeoreum Yun
Date: Thu Sep 10 2026 - 07:29:39 EST
> On 9/10/26 12:54, Yeoreum Yun wrote:
> >> On 9/7/26 10:19, Yeoreum Yun wrote:
> >>> 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@xxxxxxxxxx>
> >>> Suggested-by: Zi Yan <ziy@xxxxxxxxxx>
> >>> Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>
> >>> Reviewed-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
> >>> Tested-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
> >>> Acked-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> >>> Signed-off-by: Yeoreum Yun <yeoreum.yun@xxxxxxx>
> >>> ---
> >>> 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
> >>
> >> [...]
> >>
> >>>
> >>> - 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.
Okay. then I'll change the check_huge_shmem() to check_huge_file()
with the separate patch.
--
Sincerely,
Yeoreum Yun