Re: [PATCH v5 2/3] kselftest: mm: replace usage of /proc/self/smaps for check_huge_xxx() helper

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

On 9/10/26 12:54, Yeoreum Yun wrote:
>> On 9/7/26 10:19, Yeoreum Yun wrote:
>>> 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(). Furthermore, a subsequent
>>> madvise(MADV_HUGEPAGE) call does not split the VMA because the flag is
>>> already set.
>>>
>>> This causes split_huge_page_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.
>>>
>>> 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.
>>>
>>> Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
>>> Suggested-by: Zi Yan <ziy@nvidia.com>
>>> Reviewed-by: Zi Yan <ziy@nvidia.com>
>>> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>>> Tested-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>>> Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>>> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>>> ---
>>>  tools/testing/selftests/mm/vm_util.c | 145 ++++++++++++++++++++++-------------
>>>  tools/testing/selftests/mm/vm_util.h |   1 +
>>>  2 files changed, 92 insertions(+), 54 deletions(-)
>>>
>>> diff --git a/tools/testing/selftests/mm/vm_util.c b/tools/testing/selftests/mm/vm_util.c
>>> index 4821a3563036..dc62ce84e143 100644
>>
>> [...]
>>
>>>  
>>> -	if (hpage_size == pmd_pagesize)
>>> -		return __check_pmd_huge(addr, "AnonHugePages: ", nr_hpages, hpage_size);
>>> +static bool check_huge_type(uint64_t categories, uint64_t kpageflags,
>>> +			    enum check_huge_type type)
>>> +{
>>> +	const bool file = categories & PAGE_IS_FILE;
>>> +	const bool swapbacked = kpageflags & KPF_SWAPBACKED;
>>> +
>>> +	switch (type) {
>>> +	case CHECK_HUGE_ANON:
>>> +		return !file;
>>> +	case CHECK_HUGE_FILE:
>>> +		return file && !swapbacked;
>>> +	case CHECK_HUGE_SHMEM:
>>> +		return file & swapbacked;
>>> +	}
>>
>> Why do we even need CHECK_HUGE_SHMEM?
>>
>> That's really just a legacy thing for using smaps to identify huge pages.
>>
>> It's sufficient to identify CHECK_HUGE_FILE if you know that you have shmem mapping.
>>
>> You will not arbitrarily have non-shmem folios in a shmem mapping :)
> 
> Agree. but there seems the case where discern whethr the mapping is
> with regular file or shmem like tmpfs -- khugepaged test where using
> __shmem_ops. So I think it would be better to keep this as-is.

Let's not add or maintain unnecessary complexity.

hmem_check_huge can really just become check_huge_file.

Even file_check_huge can just be simplified.

There must be a pretty good reason why we'd want to keep this.

-- 
Cheers,

David