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
