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

[Yeoreum Yun <yeoreum.yun@arm.com>]

> 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?

Well, users currently for using /proc/self/smaps are for check vm-flags:
  - guard-regions where using check_vmflags_guard()
  - pfnmap test where uses check_vmflag_pfnmap()

AFAIK, there is no interface to get vm-flags except /proc/self/smaps,
we should add new interface but I'm not sure whether it's useful except
for test purpose.

Since for a testing, the most chance for VMA merge is when using anon
private mapping and this would be enough with allocate_isolated_mem().

-- 
Sincerely,
Yeoreum Yun