On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote: > Introduce vma[_flags]_is_mm_backed() for the purposes of identifying > mappings which are mm-managed and whose contents were placed there by core > mm's own fault path - rather than a custom ->fault handler - and which core > mm has not reserved the right to discard. > > Mappings not managed by core mm do not fall into this category, as they are > populated by their owner, and nor of course does memory-mapped I/O. > > We exclude fixed mappings as these have a layout core mm cannot assume > ordinary fault semantics over. > > hugetlb mappings are fixed mappings, but core mm owns them entirely, so > they are explicitly carved out as mm-backed, as the MADV_DODUMP check > already does. > > Droppable mappings are excluded as core mm has promised it may discard them > at any time. > > Use this functionality to update the madvise MADV_DODUMP check to test for > this rather than open-coding it. > > This replaces the VM_SPECIAL check which means it no longer checks for > VMA_IO_BIT, however this is safe as we have established the invariant that > mm-managed mappings may not set VMA_IO_BIT, so we implicitly include > these. > > No functional change intended. > > Acked-by: Zi Yan <[email protected]> > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > --- > include/linux/mm.h | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ > mm/madvise.c | 4 ++-- > 2 files changed, 52 insertions(+), 2 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 2ce68713e4c3..55320cf2c525 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1738,6 +1738,56 @@ static inline bool vma_can_merge(const struct > vm_area_struct *vma) > return vma_flags_can_merge(&vma->flags); > } > > +/** > + * vma_flags_is_mm_backed() - Do the specified VMA flags imply the mapping is > + * backed by core mm? > + * @flags: The VMA flags to test. > + * > + * An mm-backed mapping is one managed by core mm (see > + * vma_flags_is_mm_managed()) for which two further things are true: > + * > + * 1. Everything mapped was placed there by core mm's fault path (no custom > + * ->fault). > + * 2. What is mapped stays there until it is zapped or unmapped by the user.
I still dislike squeezing the VMA_DROPPABLE check in here. It's just weird semantics to squeeze pages that are *managed* by core MM (#1) but are simply always lazyfree into this check. In fact, core-mm manages (zaps) these pages, they are really just just permanently lazyfree. Open-coding "this (DUMP, UFFD, MLOCK) does not make sense for droppable mappings" is IMHO the right decision, because there you could say "dumping something that can get zapped every second does not make any sense" "placing pages through uffd does not make any sense if it can get zapped any second" "mlock'ing (and thereby allocating!) droppable mapping does not make any sense and could actually break droppable semantics" Not a hill I will die on, but I much rather have the droppable mapping be outside or have it called something nasty like vma[_flags]_is_mm_backed_or_droppable() -- Cheers, David
