> 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 > [ ... ] > No functional change intended. > > Reviewed-by: Zi Yan <[email protected]> > Reviewed-by: Suren Baghdasaryan <[email protected]> > 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/20261009-b4-mmap-prepare-vma-flag-sanify-v5-0-923b70125...@kernel.org?part=14
