> On Fri, Aug 28, 2026 at 11:17:58AM +0100, Yeoreum Yun wrote: > > > On Fri, Aug 28, 2026 at 09:11:34AM +0100, Yeoreum Yun wrote: > > > > Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on > > > > AArch64”), > > > > glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations > > > > made by memalign(). > > > > > > > > The underlying VMA may start at a different address from the aligned > > > > address returned by memalign(). Furthermore, a subsequent > > > > madvise(MADV_HUGEPAGE) call does not split the VMA because the flag is > > > > already set. > > > > > > > > This causes split_huge_page_test to fail because the check_huge_xxx() > > > > helpers incorrectly require the address returned by memalign() to > > > > match the VMA start address reported in /proc/self/smaps. > > > > > > Hmm, is the test correctly putting sentinels either side of the VMA? Any > > > test > > > that doesn't risks flaking due to unwanted VMA merges. > > > > I believe that with this change, we don’t need to worry about unwanted > > VMA merges when checking for huge pages, since the test no longer relies > > on VMA sentinels but directly checks whether the mapping is huge or not. > > We always need to worry about that though, anything that asserts stuff on a > VMA level must prevent unwanted merges first. > > I guess I'm asking you in a roundabout way to go check and if there isn't > isolation like that (i.e. mapping PROT_NONE VMAs around the VMA you want) > then to go do that :)
Oh. Sorry not to catch your intend. not for only this series but for the future usage, might it sound reasonable to add some mem alloca fucntion for the test which could replace memalign() with above concept. > I think glibc going off and mapping a bigger VMA is possibly a symptom > of this not being done. TBH, what user would generally care whether VMAs are merged or not? Anyway, it would be better to add a helper with some PROT_NONE guards to prevent unwanted VMA merges while testing. > > > > > Also, this flaky failure was not caused by a VMA merge, but by a change > > in glibc’s behavior that sets HUGEPAGE for sufficiently large areas. > > Yep your change is worthwhile reagrdless! :) Thanks :) > > > > > Might for the *NO_HUGEPAGE* setup, there would be a chance to merge > > VMA area, But since it seraches the mapping directly, it's fine. > > As above, generally we should put this protection in case, even if it's > unlikely for a VMA with VMA_NOHUGEPAGE_BIT set! Agree. let me add one for this and replace memalign() used in khugepagd and split_huge_page_test at first. > > > > > > > > > > > > > > Fix this by using /proc/self/pagemap and /proc/kpageflags instead of > > > > /proc/self/smaps to detect huge pages. > > > > > > You should probably call out the fact you're doing some refactoring here > > > also! > > > > Okay. I'll spell out with some detail. Thanks! > > Thnks! > > > > > > > > > > > > > > Reported-by: David Hildenbrand (Arm) <[email protected]> > > > > > > Should always have a Closes: tag if Reported-by: ideally. > > > > Yes. but talked with personally nothing to close. So Reported-by tag > > only. Would it be better to remove? > > Yeah or Suggested-by maybe? If he said it to you on-list then a Closes: > <lore link> works also! Okay. I'll drop the Reported-by: and change to Suggseted-by. Thanks! -- Sincerely, Yeoreum Yun
