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

["David Hildenbrand (Arm)" <david@kernel.org>]

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

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