Re: [PATCH v5 3/3] kselftest: mm: introduce alloc_isolated_mem()

[Yeoreum Yun]

> On 9/10/26 13:22, Yeoreum Yun wrote:
> > On Thu, Sep 10, 2026 at 01:14:42PM +0200, David Hildenbrand (Arm) wrote:
> >> On 9/10/26 13:02, Yeoreum Yun wrote:
> >>>
> >>> Since there is no interface to get vm_flags not via /proc/self/smaps,
> >>> It might be good to have it for preventing unwanted VMA merge.
> >>>
> >>> And might be useful for future to prevent unwated VMA merge.
> >>
> >> See my reply on why vm flags are generally not a problem. Just like other
> >> properties that are not changed during VMA merging.
> >>
> >> Let's not perform random code changes without a clear picture.
> >>
> >> And just to emphasize again: VMA merging could already be a problem before
> >> memalign() internal changes.
> >>
> >> (also observe here how we do a MADV_HUGEPAGE, so this is all rather arbitrary,
> >> which is not good)
> > 
> > As I mentioned in my previous reply, what I’m trying to prevent here is
> > a failure when checking, immediately after memory allocation,
> > that a specific vm_flag is not set.
> > 
> > Yes, I agree that this could have been a problem even before
> > the internal changes to memalign(). An unwanted VMA merge could already
> > occur at the time of memory allocation.
> > 
> > So what I’m trying to avoid is a test failure where, due to such an
> > unexpected VMA merge during allocation, the subsequent check that
> > a specific vm_flag is not present fails.
> Which is only a guard-region marker problem?

Yes. so if we remove ASSERT_FALSE(check_vmflag_guard(ptr)), TBH
we don't need this patch unless other usage comes up to prevent unwanted
VMA merge.

Would it be better to drop ASSERT_FALSE(check_vmflag_guard(ptr)) in
guard test?

-- 
Sincerely,
Yeoreum Yun