linux-toradex.git/tools/testing/vma, branch master

mm/vma: avoid losing atomic VMA flags when setting sticky VMA flags

2026-11-03T02:14:42+00:00

vma_merge_existing_range() merges an existing VMA (middle) when its
attributes have changed to match those of one or both adjacent VMAs.

Sticky flags are propagated if they are set in any of the merged VMAs. They
are initialised from vmg->vma_flags, which is assumed to contain middle's
sticky flags when the function is invoked.

However, the VMA write lock is not held for middle when they are first
populated, so concurrent updates to atomic VMA flags may occur, which will
be lost upon merge.

This can result in fork failing to propagate guard region markers and (if
file-backed) THP collapse discarding them.

Resolve this by propagating the sticky flags after middle is locked.

Make life easier by factoring this into propagate_sticky_flags(), which
treats vmg->vma_flags as its base (in case any sticky flags are set there),
updating it as sticky flags are accumulated from merged VMAs.

Also update vma_expand() to use propagate_sticky_flags() so all merge paths
utilise it.

propagate_sticky_flags() also asserts that the VMA write lock is held for
the VMA whose sticky flags are being read, with a comment explaining why.

Another means by which atomic VMA flags can fail to be observed is when the
merge is finalised in commit_merge().

rmap locks are dropped in vma_complete() before the sticky flags are
written, meaning an rmap walker can observe the VMA without sticky flags
set, which can also result in retract_page_tables() discarding guard
markers.

Resolve this by assigning the sticky flags before dropping rmap locks,
factored into commit_sticky_flags() with a write assert on the VMA being
written to.

Also remove the vma_set_flags_mask() invocation at the end of
vma_merge_existing_range() as this was introduced by commit
64212ba02e66 ("mm: implement sticky VMA flags") to propagate sticky flags,
which is now redundant with the introduction of commit_sticky_flags().

The vma_set_flags_mask() invocation at the end of vma_expand() setting
sticky flags only is also removed for the same reason.

Also update vma_merge_existing_range()'s comment to reflect the fact that
vmg->vma_flags gets updated.

Finally, update the userland VMA tests to reflect a previously missed
const-ification in vma_assert_write_locked() which would otherwise cause a
warning when building them.

Link: https://lore.kernel.org/20261023-fix-vma-atomic-v1-4-8ff4fae1fc85@kernel.org
Fixes: 2ab7f1bbafc9 ("mm/madvise: allow guard page install/remove under VMA lock")
Fixes: 49e14dabed7a ("mm: set the VM_MAYBE_GUARD flag on guard region install")
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Suggested-by: David Hildenbrand (Arm) 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Pedro Falcato 
Tested-by: Gregory Price (Meta) 
Cc: Liam R. Howlett 
Cc: Vlastimil Babka 
Cc: Mike Rapoport 
Cc: Suren Baghdasaryan 
Cc: Michal Hocko 
Cc: Jann Horn 
Cc: Davidlohr Bueso 
Cc: SJ Park 
Cc: Kees Cook 
Cc: Colin Cross 
Cc:

mm: do not unintentionally overwrite atomic VMA flags

2026-11-03T02:14:42+00:00

Patch series "mm: avoid losing atomic VMA flags", v1.

Since commit 2ab7f1bbafc9 ("mm/madvise: allow guard page install/remove
under VMA lock"), VMA_MAYBE_GUARD_BIT can be set atomically under the VMA
read lock.

However, a number of places wrongly assume the flags are stable under the
read lock, which can cause stale atomic VMA flags to overwrite existing
valid ones.

Additionally, one case in which VMA_SOFTDIRTY_BIT was overwritten is also
addressed.

This series addresses each of these, while keeping the logic inline with
existing conventions.

Each patch in this series is a hotfix.


This patch (of 4):

madvise, mlock and mprotect take a copy of a VMA's flags holding only the
VMA read lock, later writing it back under the write lock (in
madvise_update_vma(), mlock_fixup(), mlock_vma_pages_range() and
mprotect_fixup()).

This was done on the assumption that VMA flags cannot change with a read
lock held.

However this changed in commit 2ab7f1bbafc9 ("mm/madvise: allow guard page
install/remove under VMA lock"), which allowed VM_ATOMIC_SET_ALLOWED
flags (currently only VMA_MAYBE_GUARD_BIT) to be written concurrently under
a VMA read lock.

The actual write itself is safe as this is done under the VMA write lock
at which point no further concurrent writes can occur, however at this
point the stale flags mean that these callers can unintentionally overwrite
atomic flags incorrectly.

The consequences of this are significant - a missing VMA_MAYBE_GUARD_BIT
could result in page tables not being copied on fork (the vma_needs_copy()
check can return false) or being overwritten on file-backed THP
collapse (the file_backed_vma_is_retractable() can return true).

Resolve the issue by always taking care to retain existing atomic flags
when overwriting VMA flags, replacing the inconsistently named
vma_flags_reset_once() with vma_overwrite_flags() to do so, and always
invoking it when flags are overwritten like this.

Reads are a problem too - madvise, mlock and mprotect all compare VMA flags
without a VMA write lock held via vma_flags_same_pair().

This has more serious impact, as concurrent changes to atomic VMA flags can
cause two sets of VMA flags to be wrongly considered different.

For mprotect and madvise this causes a useless split, but mlock is impacted
more seriously as it can result in mm->locked_vm underflow.

Fix this by updating vma_flags_same_pair() to disregard
VM_ATOMIC_SET_ALLOWED VMAs - VMA equality is the same as VMA mergeability,
and atomic VMA flags are disregarded when comparing VMA flags for merge -
so this is justified semantically.

Additionally, remove the redundant vma_flags_same_mask() and the unused
vma_flags_same() as part of the change, and replace VM_ATOMIC_SET_ALLOWED
with VMA_ATOMIC_SET_ALLOWED, using the new VMA flag API.

Finally, update userland VMA tests to reflect the changes.

Link: https://lore.kernel.org/20261023-fix-vma-atomic-v1-0-8ff4fae1fc85@kernel.org
Link: https://lore.kernel.org/20261023-fix-vma-atomic-v1-1-8ff4fae1fc85@kernel.org
Fixes: 2ab7f1bbafc9 ("mm/madvise: allow guard page install/remove under VMA lock")
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Suggested-by: David Hildenbrand (Arm) 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Pedro Falcato 
Tested-by: Gregory Price (Meta) 
Cc: Liam R. Howlett 
Cc: Vlastimil Babka 
Cc: Mike Rapoport 
Cc: Suren Baghdasaryan 
Cc: Michal Hocko 
Cc: Jann Horn 
Cc: Davidlohr Bueso 
Cc: SJ Park 
Cc: Kees Cook 
Cc: Colin Cross 
Cc:

mm/vma: fix expansion of VMA_MIXEDMAP_BIT VMAs

2026-11-03T02:14:41+00:00

Commit ca3d76b0aa80 ("mm: add merging after mremap resize") combined
merging with expansion of mremap()'d VMAs, however it also unintentionally
disallowed the expansion of unmergeable VMAs.

Previously it was possible to expand a mixed mapping which mremap() had
already ensured was a legal expansion.

This is clearly seen in the mremap() logic, as it checks
vma_is_fixed_mapping() to determine legality of an expansion rather than
vma_can_merge().

Additionally, copy_vma() allows for a failed merge to result in a new VMA
being instantiated if MREMAP_MAYMOVE is specified.

However, this is not attempted, as a failure in vma_merge_extend() is
assumed to be an -ENOMEM failure.

Since vma_merge_extend() is used exclusively by mremap() to perform a merge
and/or expansion, resolve the issue by invoking vma_expand() for
unmergeable VMAs there.

Explicitly assert that the VMA is both non-fixed and a mixed mapping.
This provides double insurance against broken changes in future.

Note that khugepaged_enter_vma() (which vma_merge_new_range() runs) is
redundant in this case, as a mixed mapping is not subject to khugepaged.

Also update the VMA userland tests to add a required predicate.

Link: https://lore.kernel.org/20261023-vma-expansion-fix-v1-1-6142baf1f46b@kernel.org
Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize")
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Reported-by: Luiz Capitulino 
Closes: https://lore.kernel.org/all/20261023023106.515365-1-luizcap@redhat.com/
Acked-by: Vlastimil Babka (SUSE) 
Reviewed-by: Pedro Falcato 
Cc: Liam R. Howlett 
Cc: Jann Horn 
Cc: Jakub Matěna 
Cc:

mm/vma: avoid broken uffd merge on mremap

2026-10-24T08:56:42+00:00

Userfaultfd often causes unexpected interactions within mm, and does so at
the intersection of uffd, mremap() and VMA merging.

When an mremap of a VMA occurs, copy_vma_and_data() calls
mremap_userfaultfd_prep() to notify uffd of this.

However, mremap_userfaultfd_prep() simply drops the UFFD context for the
VMA if the user did not register it for remap, i.e. didn't specify the
UFFD_FEATURE_EVENT_REMAP flag.

This is OK for the VMA itself, as upon page table move, move_ptes() clears
UFFD page table flags, using vma_has_uffd_without_event_remap() to
determine whether to do so.

However, this doesn't account for merging with adjacent VMAs, whose page
tables won't have received this treatment, and thus latent UFFD markers
will be left around.

Worse, it'll break UFFD for any VMAs it is merged with. This is very
surprising behaviour for a user, who will then simply not receive UFFD
events for VMAs they ought to.

Resolve the issue by explicitly checking for this case via
vma_has_uffd_without_event_remap() in vma_merge_copied_range(), the merge
function explicitly designated for mremap() operations.

Also update the userland VMA tests accordingly.

Link: https://lore.kernel.org/20261020-uffd-remap-fix-v1-1-0f34fc181f0a@kernel.org
Fixes: 3cfd22be0ad6 ("userfaultfd: clear flag if remap event not enabled")
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Reported-by: shaos 
Closes: https://lore.kernel.org/all/20261020110748.959870-1-shawnq1@163.com/
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Gregory Price (Meta) 
Reviewed-by: Xueyuan Chen 
Cc: Liam R. Howlett 
Cc: Vlastimil Babka 
Cc: Jann Horn 
Cc: Pedro Falcato 
Cc: Mike Rapoport 
Cc: Peter Xu 
Cc: David Hildenbrand 
Cc:

mm/vma: avoid spurious write locks when mm->mm_lock_seq overflows

2026-10-24T08:56:35+00:00

So far the assumption has been that mm->mm_lock_seq overflow is benign,
resulting only in readers spuriously falling back to the mmap lock, however
it turns out that this was an unsafe assumption.

If a VMA can be spuriously considered write locked that means read lock
exclusion does not take place, and thus a VMA can end up write-locked with
concurrent readers.

Since overflow only occurs every 2^31 write lock/unlock cycles, resolve the
issue by resetting every VMA's vma->vm_lock_seq each time such an overflow
occurs.

This is done in vma_end_write_all(), which is called when the mmap write
lock is released, i.e. in mmap_write_unlock() and mmap_write_downgrade().

Care must be taken, as resetting the sequence count at overflow means
changing the seqcount of VMAs which are already attached and observable.

The mm's seqcount is guaranteed to be odd when a write lock is held, and
thus any write locked VMA will have an odd seqcount assigned.

Therefore resetting to an even value prevents spurious write locks, since
these can only occur with the mmap write lock held, at which point the mmap
seqcount will be odd.

However, vma_start_read() also checks vma->vm_lock_seq == mm->mm_lock_seq,
bailing if so (indicating a write lock).

This would cause any even reset value chosen to prevent VMA read locks from
being taken - avoid this by also checking whether the VMA seqcount is odd
before bailing on the read lock.

So far, vma->vm_lock_seq has defaulted to UINT_MAX, but this has been
unnecessary since commit e5e7fb278e59 ("mm: convert mm_lock_seq to a proper
seqcount"), since this is assigned when the VMA is still detached, and
cannot be observed.

Therefore perform both reset and initialisation of vma->vm_lock_seq by
simply setting vma->vm_lock_seq to zero.

The reset, performed in __mm_reset_vma_seqcounts(), only needs to
WRITE_ONCE() the value.

However the read of vma->vm_lock_seq in vma_start_read() needs to have
acquire semantics to pair with the smp_wmb() in do_raw_write_seqcount_end()
so a reader reading a reset value also observes VMA modifications made
under the write lock.

Since all VMA write locks were just released and the mmap write lock is
still held, there are no concurrent VMA writers.

Concurrent VMA readers are unaffected. New VMA readers observe either zero,
never a write lock, or the prior seqcount, behaving as before the reset.

Since this only occurs every 2^31 write lock/unlock cycles, the time taken
to update all VMAs is considered to be acceptable.

Also update comments, documentation and VMA userland tests to reflect the
change.

User facing effects are - dangerous races that could cause memory
corruption or NULL pointer derefences (especially on page table traversal)
are avoided.

Link: https://lore.kernel.org/20261016-fix-vma-lock-overflow-v2-1-9eb778b79b58@kernel.org
Fixes: 5e31275cc997 ("mm: add per-VMA lock and helper functions to control it")
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Reported-by: Daehyeon Ko <4ncienth@gmail.com>
Closes: https://lore.kernel.org/all/20261015143735.1630957-1-4ncienth@gmail.com/
Reviewed-by: Jose A. Perez de Azpillaga 
Tested-by: Jose A. Perez de Azpillaga 
Cc: Suren Baghdasaryan 
Cc: Liam R. Howlett 
Cc: Vlastimil Babka 
Cc: Shakeel Butt 
Cc: David Hildenbrand 
Cc: Mike Rapoport 
Cc: Michal Hocko 
Cc: Jonathan Corbet 
Cc: Randy Dunlap 
Cc: Jann Horn 
Cc: Pedro Falcato 
Cc:  # 7.3.x

mm/vma: don't remove VMA from rmap if pgoff unchanged

2026-10-24T08:56:22+00:00

When updating a VMA, vma_prepare() unconditionally removes it from its
rmap interval trees under the rmap lock, and vma_complete() reinserts it
before releasing the lock.

This is wholly unnecessary if its page offset (file rmap) or anonymous
page offset (anon rmap) is unchanged.

So, track whether they will change in the newly introduced
vp->file_pgoff_unchanged and vp->anon_pgoff_unchanged fields, and use them
to determine whether to remove the VMA or not.

The rmap lock keeps things safe as no rmap walks can concurrently occur
during the operation.

Additionally, some architectures (arm, parisc, nios2, csky) have dcache
flush rmap walkers which take only flush_dcache_mmap_lock(), which is
likewise held across the operation.

If the VMA remains in the tree, it's necessary to keep the augmented
rb_subtree_last field updated to reflect its changed range.

Provide mapping_rmap_tree_[pre, post]_update() and anon_rmap_tree_[pre,
post]_update_vma() (replacing the existing logic in the anonymous case) to
handle both the changed and unchanged cases.

For the anon rmap case, with CONFIG_DEBUG_VM_RB set, avc->cached_vma_last
is also updated when propagating in place.

When performing a VMA shrink or a split where the VMA is the lower one,
the page offset cannot change, so set the flags unconditionally in these
cases.

When merging VMAs the page offset is unchanged only in some cases, so
update init_multi_vma_prep() to set the flags only if the page offsets
remain the same.

Finally, while we're here, also update expand_upwards() similarly.

These changes ultimately result in less rmap lock contention.

Pan Deng reported results using the UnixBench/excel benchmark on a
2-socket 192 core, 384 thread x86-64 system for v7.3-rc4 with/without the
patch applied:

Execl Throughput, index score:

                    avg    %stdev      min        max
  v7.3-rc4        3511.5     0.44%    3494.5    3543.4
  + patch         4069.0     0.48%    4047.4    4109.5 (+15.9%)

Average wait on file rmap lock in ms, 5 runs per kernel:

               avg      %stdev     min       max
  v7.3-rc4    9.470     2.91%     9.070     9.820
  + patch     8.420     3.34%     8.100     8.770 (-11.1%)

Profiling data obtained during the operation highlighted the file rmap lock
as the primary source of contention.

Link: https://lore.kernel.org/20260930-speed-up-inplace-rmap-v2-1-ac1aa19708aa@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Suggested-by: Pan Deng 
Reviewed-by: Rik van Riel 
Acked-by: Lance Yang 
Tested-by: Lance Yang 
Reviewed-by: Pedro Falcato 
Cc: David Hildenbrand 
Cc: Liam R. Howlett 
Cc: Vlastimil Babka 
Cc: Mike Rapoport 
Cc: Suren Baghdasaryan 
Cc: Michal Hocko 
Cc: Harry Yoo 
Cc: Jann Horn

mm: implement and use vma_has_anon_rmap(), silence KCSAN

2026-10-24T08:56:22+00:00

Provide a function to abstract the common task of checking whether
a VMA has an anonymous reverse mapping associated with it.

If the VMA is attached, a VMA or mmap lock must be held when calling this
function.

For an attached, anonymous, VMA:

          Transition          |              VMA/mmap Lock state
 -----------------------------|-------------------------------------------
   No anon rmap to anon rmap  | Write lock/read lock + mm->page_table_lock
   Anon rmap to no anon rmap  | Write lock

vma_has_anon_rmap() never provides a false positive (the lock precludes
it), but if only a read lock is held, a negative result must be re-checked
with mm->page_table_lock held.

A VMA obtains an anonymous reverse mapping when first faulted or forked
and it is removed when it is freed.

Detached VMAs cannot be concurrently manipulated as they are removed from
the maple tree so require no guarantees.

Use data_race() to silence KCSAN about non-existent data races between
concurrent vma->anon_vma read/write on optimistic fault tests.

Update the core VMA merge/split, rmap, mremap, KSM, fork,
khugepaged and fault preparation callers which test vma->anon_vma directly
to use vma_has_anon_rmap() instead.

Finally, update comments that reference anon_vma to reference the anon rmap
instead.

Since the lockless read in reusable_anon_vma() is doing more than checking
whether the VMA has anon rmap - it is returning the anon_vma to be used on
fault - do not alter it.

There is one odd one out - file_backed_vma_is_retractable() - which holds
neither a VMA nor mmap lock and is stabilised by the file rmap lock only,
so simply add a comment to explain why it's necessary.

Link: https://lore.kernel.org/20260917-vma-is-faulted-v3-2-5c22314a72e7@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Reported-by: Guilherme Giacomo Simoes 
Closes: https://lore.kernel.org/all/20260829100034.423064-1-trintaeoitogc@gmail.com/
Closes: https://lore.kernel.org/all/20260909115723.528501-1-trintaeoitogc@gmail.com/
Reviewed-by: Pedro Falcato 
Reviewed-by: Kiryl Shutsemau (Meta) 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Lance Yang 
Cc: Alistair Popple 
Cc: Baolin Wang 
Cc: Baoquan He 
Cc: Barry Song 
Cc: Byungchul Park 
Cc: Chengming Zhou 
Cc: Chris Li 
Cc: Dev Jain 
Cc: Gregory Price 
Cc: Harry Yoo 
Cc: "Huang, Ying" 
Cc: Jann Horn 
Cc: Joshua Hahn 
Cc: Kairui Song 
Cc: Kemeng Shi 
Cc: Liam R. Howlett 
Cc: Matthew Brost 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Muchun Song 
Cc: Nhat Pham 
Cc: Oscar Salvador 
Cc: Peter Xu 
Cc: Rakie Kim 
Cc: Rik van Riel 
Cc: Ryan Roberts 
Cc: Shakeel Butt 
Cc: Suren Baghdasaryan 
Cc: Vlastimil Babka 
Cc: xu xin 
Cc: Zi Yan

mm/vma: const-ify vma_assert_stabilised() and associated functions

2026-10-24T08:56:21+00:00

Patch series "mm: implement and use vma_has_anon_rmap(), silence KCSAN".

Provide a function to abstract the common task of checking whether a VMA
has an anonymous reverse mapping associated with it.

In the first patch, const-ify vma_assert_stabilised() and related
functions so that vma_has_anon_rmap() can reference a const vma pointer.

In the second patch, introduce vma_has_anon_rmap().

Finally in the third patch, update comments referencing anon_vma to
instead reference the anon rmap to abstract this conceptually to avoid
confusion.

There are still other functions which reference anon_vma directly, those
can be addressed in a follow up.


This patch (of 3):

The vma pointers are not modified in any of these functions so make it
official by const-ify them.

Propagate this throughout the call stack.

No functional change intended.

Link: https://lore.kernel.org/20260917-vma-is-faulted-v3-0-5c22314a72e7@kernel.org
Link: https://lore.kernel.org/20260917-vma-is-faulted-v3-1-5c22314a72e7@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Reviewed-by: Zi Yan 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Pedro Falcato  
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Lance Yang 
Cc: Alistair Popple 
Cc: Baolin Wang 
Cc: Baoquan He 
Cc: Barry Song 
Cc: Byungchul Park 
Cc: Chengming Zhou 
Cc: Chris Li 
Cc: Dev Jain 
Cc: Gregory Price 
Cc: Guilherme Giacomo Simoes 
Cc: Harry Yoo 
Cc: "Huang, Ying" 
Cc: Jann Horn 
Cc: Joshua Hahn 
Cc: Kairui Song 
Cc: Kemeng Shi 
Cc: Liam R. Howlett 
Cc: Matthew Brost 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Muchun Song 
Cc: Nhat Pham 
Cc: Oscar Salvador 
Cc: Peter Xu 
Cc: Rakie Kim 
Cc: Rik van Riel 
Cc: Ryan Roberts 
Cc: Shakeel Butt 
Cc: Suren Baghdasaryan 
Cc: Vlastimil Babka 
Cc: xu xin

mm: eliminate VM_SPECIAL, VMA_SPECIAL_FLAGS

2026-10-24T08:56:20+00:00

Every user of the VM_SPECIAL or VMA_SPECIAL_FLAGS has now been converted to
predicates which explicitly express what is actually being checked for
rather than the nebulous concept of possessing 'special' VMA flags.

In any case 'special' is not so special a term of art in mm - it includes
VDSO/VVAR mappings, special in the sense of vm_normal_folio() and probably
other cases too.

Therefore make things less special by eliminating these now unused flags.

No functional change intended.

Link: https://lore.kernel.org/20261013-b4-mmap-prepare-vma-flag-sanify-v6-37-1aa3c9b139f9@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Acked-by: Zi Yan 
Acked-by: David Hildenbrand (Arm) 
Cc: Liam R. Howlett 
Cc: Vlastimil Babka 
Cc: Jann Horn 
Cc: Pedro Falcato 
Cc: Mike Rapoport 
Cc: Suren Baghdasaryan 
Cc: Michal Hocko 
Cc: Jonathan Corbet 
Cc: Greg Kroah-Hartman 
Cc: Dennis Dalessandro 
Cc: Jason Gunthorpe 
Cc: Leon Romanovsky 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Andrii Nakryiko 
Cc: Eduard Zingerman 
Cc: Kumar Kartikeya Dwivedi 
Cc: Baolin Wang 
Cc: Nico Pache 
Cc: Ryan Roberts 
Cc: Dev Jain 
Cc: Barry Song 
Cc: Lance Yang 
Cc: Usama Arif 
Cc: Kiryl Shutsemau 
Cc: Doug Gilbert 
Cc: James Bottomley 
Cc: Martin K. Petersen 
Cc: Simona Vetter 
Cc: Helge Deller 
Cc: Sebastian Reichel 
Cc: John Hubbard 
Cc: Peter Xu 
Cc: Masami Hiramatsu 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Arnaldo Carvalho de Melo 
Cc: Namhyung Kim 
Cc: Mark Rutland 
Cc: Rik van Riel 
Cc: Harry Yoo 
Cc: Juri Lelli 
Cc: Vincent Guittot 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Will Deacon 
Cc: Aneesh Kumar K.V 
Cc: Nicholas Piggin 
Cc: Arnd Bergmann 
Cc: Muchun Song 
Cc: Oscar Salvador 
Cc: Matthew Wilcox (Oracle) 
Cc: Jan Kara 
Cc: Marc Zyngier 
Cc: Oliver Upton 
Cc: Catalin Marinas 
Cc: Madhavan Srinivasan 
Cc: Anup Patel 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Christian Borntraeger 
Cc: Janosch Frank 
Cc: Claudio Imbrenda 
Cc: Alexander Gordeev 
Cc: Gerald Schaefer 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: David S. Miller 
Cc: Andreas Larsson 
Cc: Al Viro 
Cc: Christian Brauner 
Cc: Matthew Brost 
Cc: Joshua Hahn 
Cc: Rakie Kim 
Cc: Byungchul Park 
Cc: Gregory Price 
Cc: Ying Huang 
Cc: Alistair Popple 
Cc: Chris Li 
Cc: Kairui Song 
Cc: Kemeng Shi 
Cc: Nhat Pham 
Cc: Baoquan He 
Cc: Youngjun Park 
Cc: Johannes Weiner 
Cc: Qi Zheng 
Cc: Shakeel Butt 
Cc: Axel Rasmussen 
Cc: Yuanchu Xie 
Cc: Wei Xu 
Cc: Chengming Zhou 
Cc: Michal Hocko 
Cc: Miklos Szeredi 
Cc: Xu Xin 
Cc: Ihor Solodrai 
Cc: Bert Karwatzki

mm/vma: introduce vma[_flags]_is_mm_backed()

2026-10-24T08:56:18+00:00

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.

Link: https://lore.kernel.org/20261013-b4-mmap-prepare-vma-flag-sanify-v6-30-1aa3c9b139f9@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) 
Signed-off-by: Andrew Morton 
Acked-by: Zi Yan 
Acked-by: David Hildenbrand (Arm) 
Cc: Liam R. Howlett 
Cc: Vlastimil Babka 
Cc: Jann Horn 
Cc: Pedro Falcato 
Cc: Mike Rapoport 
Cc: Suren Baghdasaryan 
Cc: Michal Hocko 
Cc: Jonathan Corbet 
Cc: Greg Kroah-Hartman 
Cc: Dennis Dalessandro 
Cc: Jason Gunthorpe 
Cc: Leon Romanovsky 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Andrii Nakryiko 
Cc: Eduard Zingerman 
Cc: Kumar Kartikeya Dwivedi 
Cc: Baolin Wang 
Cc: Nico Pache 
Cc: Ryan Roberts 
Cc: Dev Jain 
Cc: Barry Song 
Cc: Lance Yang 
Cc: Usama Arif 
Cc: Kiryl Shutsemau 
Cc: Doug Gilbert 
Cc: James Bottomley 
Cc: Martin K. Petersen 
Cc: Simona Vetter 
Cc: Helge Deller 
Cc: Sebastian Reichel 
Cc: John Hubbard 
Cc: Peter Xu 
Cc: Masami Hiramatsu 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Arnaldo Carvalho de Melo 
Cc: Namhyung Kim 
Cc: Mark Rutland 
Cc: Rik van Riel 
Cc: Harry Yoo 
Cc: Juri Lelli 
Cc: Vincent Guittot 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Will Deacon 
Cc: Aneesh Kumar K.V 
Cc: Nicholas Piggin 
Cc: Arnd Bergmann 
Cc: Muchun Song 
Cc: Oscar Salvador 
Cc: Matthew Wilcox (Oracle) 
Cc: Jan Kara 
Cc: Marc Zyngier 
Cc: Oliver Upton 
Cc: Catalin Marinas 
Cc: Madhavan Srinivasan 
Cc: Anup Patel 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Christian Borntraeger 
Cc: Janosch Frank 
Cc: Claudio Imbrenda 
Cc: Alexander Gordeev 
Cc: Gerald Schaefer 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: David S. Miller 
Cc: Andreas Larsson 
Cc: Al Viro 
Cc: Christian Brauner 
Cc: Matthew Brost 
Cc: Joshua Hahn 
Cc: Rakie Kim 
Cc: Byungchul Park 
Cc: Gregory Price 
Cc: Ying Huang 
Cc: Alistair Popple 
Cc: Chris Li 
Cc: Kairui Song 
Cc: Kemeng Shi 
Cc: Nhat Pham 
Cc: Baoquan He 
Cc: Youngjun Park 
Cc: Johannes Weiner 
Cc: Qi Zheng 
Cc: Shakeel Butt 
Cc: Axel Rasmussen 
Cc: Yuanchu Xie 
Cc: Wei Xu 
Cc: Chengming Zhou 
Cc: Michal Hocko 
Cc: Miklos Szeredi 
Cc: Xu Xin 
Cc: Ihor Solodrai 
Cc: Bert Karwatzki