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
