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?
-- Cheers, David
