Re: [PATCH v3 17/40] mm/vma: add and use vma_[flags]_is_fixed_mapping

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

On Fri, Sep 25, 2026 at 10:27:15PM -0400, Zi Yan wrote:
> On Thu Sep 17, 2026 at 12:22 PM EDT, Lorenzo Stoakes (ARM) wrote:
> > This determines whether a VMA cannot be expanded or merged because what
> > they mapped was determined to be a set size at mmap time.
> >
> > This typically refers to kernel-owned mappings, however VMA_DONTEXPAND_BIT
> > is not reliably set alongside VMA_PFNMAP_BIT or VMA_MIXEDMAP_BIT, so we
> > must explicitly test for this for now.
> >
> > We also explicitly test for VMA_PFNMAP_BIT as VMA_DONTEXPAND_BIT may not be
> > set for VMA_PFNMAP_BIT's despite the one implying the other.
> >
> > Use this predicate in vma_flags_can_merge() and in check_prep_vma() in the
> > mremap logic testing to see if mremap() can expand the VMA. The criteria
> > for khugepaged and MADV_COLLAPSE eligibility in
> > __thp_vma_allowable_orders() are precisely those for mergeability, so use
> > vma_can_merge() there (with an expanded comment).
> >
> > This obviates the need for the VM_NO_KHUGEPAGED mask, so remove it.
> >
> > Hugetlb VMAs remain excluded from khugepaged as hugetlbfs always sets
> > VMA_DONTEXPAND_BIT.
> >
> > Also update the userland VMA tests to reflect the change.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > ---
> >  include/linux/mm.h              | 39 +++++++++++++++++++++++++++++++++++----
> >  mm/huge_memory.c                | 11 +++++++----
> >  mm/mremap.c                     |  5 ++---
> >  tools/testing/vma/include/dup.h | 16 +++++++++++++++-
> >  4 files changed, 59 insertions(+), 12 deletions(-)
> >
> <snip>
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 4cd917f77f3f..4d0acd9a1099 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -212,11 +212,14 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >  		return in_pf ? orders : 0;
> >
> >  	/*
> > -	 * khugepaged special VMA and hugetlb VMA.
> > -	 * Must be checked after dax since some dax mappings may have
> > -	 * VM_MIXEDMAP set.
> > +	 * khugepaged moves data from VMAs once collapsed, after they have been
> > +	 * faulted in, relying on refaulting for file-backed memory.
> > +	 *
> > +	 * Kernel-owned mappings cannot be reliably reconstructed from page
> > +	 * faults, and fixed mappings (including hugetlb) may not be marked as
> > +	 * kernel-owned - precisely the mappings which cannot be merged.
> >  	 */
> > -	if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
> > +	if (!in_pf && !smaps && !vma_can_merge(vma))
>
> I wonder if a function alias would improve the code readability.
> Basically,
>
> #define vma_no_khugepaged vma_can_merge
>
> or just make vma_no_khugepaged static inline. And move the comment to
> the function.

Hmm yeah, I'm not sure, I think given it's here and commented it's OK and
avoids having to have a special snowflake entry for khugepaged, so unless
it were referenced again elsewhere it's ok like this?

If it gets used elsewhere in the THP code it could be relocated then maybe?

>
> Regardless, this patch makes sense to me.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>

Thanks! :)

>
>
> --
> Best Regards,
> Yan, Zi
>

--
Cheers, Lorenzo