On 9/17/26 18:22, 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.
Of course I have to bitch about the naming :) Intuitively: kernel owned vs ... user owned? No, it's kernel owned vs core-mm owned. Which implies core-mm is not part of the kernel? Yes, this is confusing. ;) I assume you're coming from "map_kernel_pages*", but that's rather "kernel memory" and not "kernel owned". Usually we say "driver owned" when not talking about pagecache/anon. Or user vs. kernel memory. So is it really all about "is this (excluding CoW) no ordinary user memory that we would track through the rmap" ? > > 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(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 2a92193ac6a5..cab29d6e15c1 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1612,6 +1612,44 @@ static inline bool vma_is_shared_maywrite(const struct > vm_area_struct *vma) > return is_shared_maywrite(&vma->flags); > } > > +/** > + * vma_flags_is_kernel_owned() - Do the specified VMA flags indicate that the > + * contents of the VMA are owned by the kernel rather than the core mm? > + * @flags: The VMA flags to test. > + * > + * A kernel-owned mapping is one whose contents are established and > controlled > + * by the kernel, typically a driver, rather than by the core mm's fault and > + * rmap machinery. > + * > + * The mapping may be memory-mapped I/O, kernel-allocated pages or ordinary > + * pages the owner has chosen to map itself (shmem via a PFN map, for > instance). > + * > + * In all cases the core mm must not populate, reclaim, migrate, > copy-on-write > + * or merge it of its own accord. > + * > + * Pages mapped this way are not necessarily reference counted or map > counted. > + * > + * Returns: true if the flags indicate a kernel-owned mapping. > + */ > +static inline bool vma_flags_is_kernel_owned(const vma_flags_t *flags) > +{ > + return vma_flags_test_any(flags, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT, > + VMA_IO_BIT); I thought we have cases where we drivers insert pages and neither set VMA_PFNMAP_BIT nor VMA_MIXEDMAP_BIT. I assume vmf_insert_page_mkwrite() is fine because it is DAX doing it (should we limit this interface to DAX?). -- Cheers, David
