Re: [Patch mm-hotfixes v5] mm/page_vma_mapped: fix device-private PMD handling

[Lance Yang]

On 2026/7/2 00:46, Klara Modin wrote:
[...]
> > > > My only guess here would be that the compiler evaluates
> > > > !softleaf_is_migration(entry) to always be true and optimises away the
> > > > !check_pmd(softleaf_to_pfn(entry), pvmw) which is why this worked
> > > > before?
> > >
> > > Weird, we enter this path only with
> > >
> > > pmd_trans_huge(pmde) || pmd_is_migration_entry(pmde) ||
> > > pmd_is_device_private_entry(pmde)
> > >
> > > If any one of these would compile for !CONFIG_TRANSPARENT_HUGEPAGE that would be
> > > odd.
> > >
> > > pmd_is_device_private_entry() is hard-coded to false unless
> > > CONFIG_ARCH_ENABLE_THP_MIGRATION. Which is only selected with
> > > ARCH_ENABLE_THP_MIGRATION.
> > >
> > > pmd_trans_huge() as well.
> > >
> > > Maybe it's struggling with pmd_is_migration_entry() on some (older) compilers?
> > > (not innlining stuff and not properly optimizing it out).
>
> It's a GCC 16 cross-compiler for armv6 so I wouldn't call it old :)
>
> > > The whole conditional must be optimized out.
> >
> > Right. Kinda weird if compiler didn't fold
> >
> > pmd_trans_huge(pmde) || pmd_is_migration_entry(pmde) ||
> > pmd_is_device_private_entry(pmde)
> >
> > away here ...
> >
> > > We could check for IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) right at the start
> > > to make it easier for the compiler:
> >
> > +1, explicit THP guard should do the trick :)
> >
> > > if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) &&
> > >     (pmd_trans_huge(pmde) || pmd_is_migration_entry(pmde) ||
> > >      pmd_is_device_private_entry(pmde))) {
> >
> > Klara, could you try with this change and see if it fixes the build?
> >
> > Thanks, Lance
>
> This does indeed make it build.

Good to know, thanks for testing!