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

[David Hildenbrand (Arm)]

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

It's really only guest-region code that needs this.

> 
>>
>> 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. 
Only for the cases that actually really needs this, which is in my understanding
guard-regions.

And I repeat, this is not a memalign() problem.

-- 
Cheers,

David