On Mon, Oct 12, 2026 at 08:45:17PM +0200, David Hildenbrand (Arm) wrote: > 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"
Yeah, I am starting to come over to your point of view on this. It sucks that we have to manually do the droppable check, and I still worry callers will miss this as a result, but at least the flag has a specific, non-vague purpose. Rather than keep on trying to fit droppable into the definition, which should be as clear as possible, it does seem better to just drop the droppable check. It's nearly equivalent to the mergeable check, except that it allows hugetlb (the eternal exception), but that means we can now define mergeability in terms of mm-backing which is really nice. It also lets me avoid a case where I check mergeability in a non-merge situation (can just drop anything like that). As well as the cases you mention. > > 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() Yeah I think best not, the flag is clearly defined, so we can live with checking it manually. My concern was people forgetting to account for it, but I guess we just have to live with that in general (ugh). Maybe later we can think of a bright idea as to how to define some semantics that include it, but that's one for the future anyway. -- Cheers, Lorenzo
