On Mon, Oct 12, 2026 at 08:06:41PM +0200, David Hildenbrand (Arm) wrote: > On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote: > > Rather than referring to VMA flags with uncertain meaning, add a new > > predicate that explicitly describes what absence of the VMA_PFNMAP_BIT and > > VMA_MIXEDMAP_BIT flags means, and then refer to that function for > > determining VMA mergeability. > > > > If neither of these flags are set, that means the contents of the mapping > > are managed by core mm. > > > > Otherwise they are instead owned by some other kernel component, usually a > > driver: the memory may be MMIO, kernel-allocated pages or even ordinary > > pages the driver maps itself, but core mm must not populate, reclaim, > > migrate, copy-on-write or merge the range itself. > > > > We initially also treat VMA_IO_BIT as implying a mapping is not mm-managed, > > as by implication it cannot be. (mlock() also sets VMA_IO_BIT transiently > > on ordinary VMAs while locking them, which is addressed later in this > > series.) > > > > However the intent is to in future remove this, as no mapping should be > > marked as an I/O mapping without also being marked with VMA_PFNMAP_BIT. > > > > This forms the basis of further work intended to improve how we express VMA > > properties such as this. > > > > Also update the VMA userland tests to reflect the change. > > > > No functional change intended. > > > > Reviewed-by: Zi Yan <[email protected]> > > Reviewed-by: Suren Baghdasaryan <[email protected]> > > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > > --- > > include/linux/mm.h | 53 > > ++++++++++++++++++++++++++++++++++++++++- > > tools/testing/vma/include/dup.h | 29 +++++++++++++++++++++- > > 2 files changed, 80 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 97e1eb4fe3a4..83953757735a 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -1612,6 +1612,41 @@ static inline bool vma_is_shared_maywrite(const > > struct vm_area_struct *vma) > > return is_shared_maywrite(&vma->flags); > > } > > > > +/** > > + * vma_flags_is_mm_managed() - Do the specified VMA flags indicate that the > > + * contents of the VMA are managed by core mm? > > + * @flags: The VMA flags to test. > > + * > > + * Such a mapping is one established by a simple mmap() or brk() with no > > driver > > + * or other kernel component involved. > > + * > > + * They are rmappable, and core mm services rmap operations including > > reclaim, > > + * as well as population, CoW and merge/split (if eligible). > > I assume ->fault returning some kernel allocations (VM_DONTEXPAND set but none > of the others) will currently contradict to that. But hopefully we'll clean > that > up in the future (or improve the documentation to cover them as well).
They really shouldn't be, but that's one for the future I guess. I hate that we allowed ->fault to be that 'flexible'. VM_DONTEXPAND is already a weird case that needs rethinking/renaming I think anyway. > > Acked-by: David Hildenbrand (Arm) <[email protected]> Thanks! > > -- > Cheers, > > David -- Cheers, Lorenzo
