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
