On Thu Sep 17, 2026 at 12:22 PM EDT, Lorenzo Stoakes (ARM) wrote: > Rather than referring to VMA flags with uncertain meaning, add a new > predicate that explicitly describes what possession of the VMA_PFNMAP_BIT > or VMA_MIXEDMAP_BIT flags mean, and then refer to that function for > determining VMA mergeability. > > Either flag means the contents of the mapping are owned by the kernel, > usually a driver, rather than by the core mm: the memory may be MMIO, > kernel-allocated pages or even ordinary pages the driver maps itself, but > the core must not populate, reclaim, migrate, copy-on-write or merge the > range on its own initiative. > > We initially also include VMA_IO_BIT here, as by implication, these must be > kernel-owned. (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. > > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > --- > include/linux/mm.h | 56 > ++++++++++++++++++++++++++++++++++++++++- > tools/testing/vma/include/dup.h | 29 ++++++++++++++++++++- > 2 files changed, 83 insertions(+), 2 deletions(-) >
LGTM. Reviewed-by: Zi Yan <[email protected]> -- Best Regards, Yan, Zi
