Thread (81 messages) 81 messages, 3 authors, 2d ago

Re: [PATCH v5 30/38] mm/vma: introduce vma[_flags]_is_mm_backed()

flat view

From: "David Hildenbrand (Arm)" <david@kernel.org>
Date: 2026-10-12 18:45:53
Also in: bpf, dri-devel, fuse-devel, kvm, kvm-riscv, kvmarm, linux-arch, linux-doc, linux-fbdev, linux-fsdevel, linux-mm, linux-perf-users, linux-rdma, linux-riscv, linux-s390, linux-scsi, linux-sound, linux-trace-kernel, linux-usb, lkml, selinux, sparclinux

On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote:
quoted hunk ↗ jump to hunk
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 <ziy@nvidia.com>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help