On 10/12/26 20:45, 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" > > 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()
Noting that that does not make sense, as we would have to reve -- Cheers, David
