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

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

On Thu, Sep 10, 2026 at 12:45:39PM +0200, David Hildenbrand (Arm) wrote:
> On 9/10/26 12:31, Yeoreum Yun wrote:
> >> 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()
> 
> 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).

Yes. That's why I'm think it would be good to use alloc_isolated_mem()
in case of ANON mapping for this case.

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

No. what I want to say including the patch #3 is for the above case
where you point out -- ASSERT_FALSE(check_vmflag_guard(ptr)).

Since we don't have any interface to check vm_flags execpt smap
and for memory mmaped with anon would have a chance to merge,
We need something to replace memalign() with preventing unexpected VMA
merge. (But I forgot to change the those case in guard test case).

-- 
Sincerely,
Yeoreum Yun