> 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]>
Sashiko has reviewed this patch and found no issues. It looks great! -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260914-b4-mmap-prepare-vma-flag-sanify-v2-0-7d9781ed5...@kernel.org?part=15
