Re: [PATCH v6 30/39] mm/vma: introduce vma[_flags]_is_mm_backed()
flat view
From: "David Hildenbrand (Arm)" <david@kernel.org>
Date: 2026-10-13 15:31:48
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-usb, linuxppc-dev, lkml, selinux, sparclinux
On 10/13/26 17:05, 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.
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.
Use this functionality to update the madvise MADV_DODUMP check to test for
this rather than open-coding it.
Also update vma_flags_can_merge() so it is written in terms of
vma_flags_is_mm_backed() - all mm-backed mappings can be merged except
hugetlb mappings, whose flags and fields do not completely describe them.
Also update __thp_vma_allowable_orders() to use vma_is_mm_backed() rather
than testing for mergeability, which is irrelevant to this function.
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>
---
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David