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 :) I think glibc going off and mapping a bigger VMA is possibly a symptom of this not being done. > > 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! :) > > 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! > > > > > > > > > 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! -- Cheers, Lorenzo
