Re: [PATCH v5 0/3] kselftest: mm: fix some failure of split_huge_page_test

[David Hildenbrand (Arm)]

On 9/7/26 10:19, Yeoreum Yun wrote:
> 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.
> 
> Also, current usage of memalign() would result memory area may
> unexpectedly merge with an adjacent VMA, causing tests
> that inspect it through /proc/self/smaps to fail.
I'm not particularly happy about this.

Relying on VMA merging details rather hints that we shouldn't be using smaps to
query some stats/properties.

Which exact things are test querying through /proc/self/smaps? Could we convert
the code to just query that stuff through different interfaces?

-- 
Cheers,

David