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

On 9/10/26 12:31, Yeoreum Yun wrote:

quoted

On 9/7/26 10:19, Yeoreum Yun wrote:

quoted

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()

Most vm-flags should not be an issue when it comes to merging. The only
exception are vmflags that do not prevent VMA merging.

So it's VM_SOFTDIRTY and VM_MAYBE_GUARD. And I agree that for guard-regions.c we
likely have to care such that we don't merge by accident with other VMAs (guard
regions).

But that's independent of memalign.

ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0);
ASSERT_FALSE(check_vmflag_guard(ptr));

could be problematic on its own (unlikely but possible).

For other flags, you really only have to find the smaps area that covers the
given address and look at the vm-flags.

Or am I missing something important?

(merging vnas with VM_PFNMAP is impossible right now IIRC)

-- 
Cheers,

David