> 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
