Re: [PATCH v3 2/2] kselftest: mm: replace usage of /proc/self/smaps for check_huge_xxx() helper

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

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) <david@kernel.org>
> >
> > 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