linux.git/mm/memory.c, branch v7.1-rc2

mm: on remap assert that input range within the proposed VMA

2026-04-05T20:53:45+00:00

Now we have range_in_vma_desc(), update remap_pfn_range_prepare() to check
whether the input range in contained within the specified VMA, so we can
fail at prepare time if an invalid range is specified.

This covers the I/O remap mmap actions also which ultimately call into
this function, and other mmap action types either already span the full
VMA or check this already.

Link: https://lkml.kernel.org/r/0fc1092f4b74f3f673a58e4e3942dc83f336dd85.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Reviewed-by: Suren Baghdasaryan 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: add mmap_action_map_kernel_pages[_full]()

2026-04-05T20:53:45+00:00

A user can invoke mmap_action_map_kernel_pages() to specify that the
mapping should map kernel pages starting from desc->start of a specified
number of pages specified in an array.

In order to implement this, adjust mmap_action_prepare() to be able to
return an error code, as it makes sense to assert that the specified
parameters are valid as quickly as possible as well as updating the VMA
flags to include VMA_MIXEDMAP_BIT as necessary.

This provides an mmap_prepare equivalent of vm_insert_pages().  We
additionally update the existing vm_insert_pages() code to use
range_in_vma() and add a new range_in_vma_desc() helper function for the
mmap_prepare case, sharing the code between the two in range_is_subset().

We add both mmap_action_map_kernel_pages() and
mmap_action_map_kernel_pages_full() to allow for both partial and full VMA
mappings.

We update the documentation to reflect the new features.

Finally, we update the VMA tests accordingly to reflect the changes.

Link: https://lkml.kernel.org/r/926ac961690d856e67ec847bee2370ab3c6b9046.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Reviewed-by: Suren Baghdasaryan 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: add mmap_action_simple_ioremap()

2026-04-05T20:53:43+00:00

Currently drivers use vm_iomap_memory() as a simple helper function for
I/O remapping memory over a range starting at a specified physical address
over a specified length.

In order to utilise this from mmap_prepare, separate out the core logic
into __simple_ioremap_prep(), update vm_iomap_memory() to use it, and add
simple_ioremap_prepare() to do the same with a VMA descriptor object.

We also add MMAP_SIMPLE_IO_REMAP and relevant fields to the struct
mmap_action type to permit this operation also.

We use mmap_action_ioremap() to set up the actual I/O remap operation once
we have checked and figured out the parameters, which makes
simple_ioremap_prepare() easy to implement.

We then add mmap_action_simple_ioremap() to allow drivers to make use of
this mode.

We update the mmap_prepare documentation to describe this mode.  Finally,
we update the VMA tests to reflect this change.

Link: https://lkml.kernel.org/r/a08ef1c4542202684da63bb37f459d5dbbeddd91.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Reviewed-by: Suren Baghdasaryan 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: various small mmap_prepare cleanups

2026-04-05T20:53:41+00:00

Patch series "mm: expand mmap_prepare functionality and usage", v4.

This series expands the mmap_prepare functionality, which is intended to
replace the deprecated f_op->mmap hook which has been the source of bugs
and security issues for some time.

This series starts with some cleanup of existing mmap_prepare logic, then
adds documentation for the mmap_prepare call to make it easier for
filesystem and driver writers to understand how it works.

It then importantly adds a vm_ops->mapped hook, a key feature that was
missing from mmap_prepare previously - this is invoked when a driver which
specifies mmap_prepare has successfully been mapped but not merged with
another VMA.

mmap_prepare is invoked prior to a merge being attempted, so you cannot
manipulate state such as reference counts as if it were a new mapping.

The vm_ops->mapped hook allows a driver to perform tasks required at this
stage, and provides symmetry against subsequent vm_ops->open,close calls.

The series uses this to correct the afs implementation which wrongly
manipulated reference count at mmap_prepare time.

It then adds an mmap_prepare equivalent of vm_iomap_memory() -
mmap_action_simple_ioremap(), then uses this to update a number of drivers.

It then splits out the mmap_prepare compatibility layer (which allows for
invocation of mmap_prepare hooks in an mmap() hook) in such a way as to
allow for more incremental implementation of mmap_prepare hooks.

It then uses this to extend mmap_prepare usage in drivers.

Finally it adds an mmap_prepare equivalent of vm_map_pages(), which lays
the foundation for future work which will extend mmap_prepare to DMA
coherent mappings.


This patch (of 21):

Rather than passing arbitrary fields, pass a vm_area_desc pointer to mmap
prepare functions to mmap prepare, and an action and vma pointer to mmap
complete in order to put all the action-specific logic in the function
actually doing the work.

Additionally, allow mmap prepare functions to return an error so we can
error out as soon as possible if there is something logically incorrect in
the input.

Update remap_pfn_range_prepare() to properly check the input range for the
CoW case.

Also remove io_remap_pfn_range_complete(), as we can simply set up the
fields correctly in io_remap_pfn_range_prepare() and use
remap_pfn_range_complete() for this.

While we're here, make remap_pfn_range_prepare_vma() a little neater, and
pass mmap_action directly to call_action_complete().

Then, update compat_vma_mmap() to perform its logic directly, as
__compat_vma_map() is not used by anything so we don't need to export it.

Also update compat_vma_mmap() to use vfs_mmap_prepare() rather than
calling the mmap_prepare op directly.

Finally, update the VMA userland tests to reflect the changes.

Link: https://lkml.kernel.org/r/cover.1774045440.git.ljs@kernel.org
Link: https://lkml.kernel.org/r/99f408e4694f44ab12bdc55fe0bd9685d3bd1117.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm/memory: fix PMD/PUD checks in follow_pfnmap_start()

2026-04-05T20:53:37+00:00

follow_pfnmap_start() suffers from two problems:

(1) We are not re-fetching the pmd/pud after taking the PTL

Therefore, we are not properly stabilizing what the lock actually
protects.  If there is concurrent zapping, we would indicate to the
caller that we found an entry, however, that entry might already have
been invalidated, or contain a different PFN after taking the lock.

Properly use pmdp_get() / pudp_get() after taking the lock.

(2) pmd_leaf() / pud_leaf() are not well defined on non-present entries

pmd_leaf()/pud_leaf() could wrongly trigger on non-present entries.

There is no real guarantee that pmd_leaf()/pud_leaf() returns something
reasonable on non-present entries.  Most architectures indeed either
perform a present check or make it work by smart use of flags.

However, for example loongarch checks the _PAGE_HUGE flag in pmd_leaf(),
and always sets the _PAGE_HUGE flag in __swp_entry_to_pmd().  Whereby
pmd_trans_huge() explicitly checks pmd_present(), pmd_leaf() does not do
that.

Let's check pmd_present()/pud_present() before assuming "the is a present
PMD leaf" when spotting pmd_leaf()/pud_leaf(), like other page table
handling code that traverses user page tables does.

Given that non-present PMD entries are likely rare in VM_IO|VM_PFNMAP, (1)
is likely more relevant than (2).  It is questionable how often (1) would
actually trigger, but let's CC stable to be sure.

This was found by code inspection.

Link: https://lkml.kernel.org/r/20260323-follow_pfnmap_fix-v1-1-5b0ec10872b3@kernel.org
Fixes: 6da8e9634bb7 ("mm: new follow_pfnmap API")
Signed-off-by: David Hildenbrand (Arm) 
Acked-by: Mike Rapoport (Microsoft) 
Reviewed-by: Lorenzo Stoakes (Oracle) 
Cc: Liam Howlett 
Cc: Michal Hocko 
Cc: Peter Xu 
Cc: Suren Baghdasaryan 
Cc: Vlastimil Babka 
Cc: 
Signed-off-by: Andrew Morton

mm: introduce is_pmd_order helper

2026-04-05T20:53:29+00:00

In order to add mTHP support to khugepaged, we will often be checking if a
given order is (or is not) a PMD order.  Some places in the kernel already
use this check, so lets create a simple helper function to keep the code
clean and readable.

Link: https://lkml.kernel.org/r/20260325114022.444081-3-npache@redhat.com
Signed-off-by: Nico Pache 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Baolin Wang 
Reviewed-by: Dev Jain 
Reviewed-by: Wei Yang 
Reviewed-by: Lance Yang 
Reviewed-by: Barry Song 
Reviewed-by: Zi Yan 
Reviewed-by: Pedro Falcato 
Reviewed-by: Lorenzo Stoakes 
Suggested-by: Lorenzo Stoakes 
Cc: Alistair Popple 
Cc: Andrea Arcangeli 
Cc: Anshuman Khandual 
Cc: Brendan Jackman 
Cc: Byungchul Park 
Cc: Catalin Marinas 
Cc: David Rientjes 
Cc: Gregory Price 
Cc: "Huang, Ying" 
Cc: Hugh Dickins 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Johannes Weiner 
Cc: Jonathan Corbet 
Cc: Joshua Hahn 
Cc: Kefeng Wang 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes (Oracle) 
Cc: "Masami Hiramatsu (Google)" 
Cc: Mathieu Desnoyers 
Cc: Matthew Brost 
Cc: Matthew Wilcox (Oracle) 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Nanyong Sun 
Cc: Peter Xu 
Cc: Rafael Aquini 
Cc: Rakie Kim 
Cc: Randy Dunlap 
Cc: Ryan Roberts 
Cc: Shivank Garg 
Cc: Steven Rostedt 
Cc: Suren Baghdasaryan 
Cc: Takashi Iwai (SUSE) 
Cc: Thomas Hellström 
Cc: Usama Arif 
Cc: Vishal Moola (Oracle) 
Cc: Vlastimil Babka 
Cc: Will Deacon 
Cc: Yang Shi 
Cc: Zach O'Keefe 
Signed-off-by: Andrew Morton

mm: consolidate anonymous folio PTE mapping into helpers

2026-04-05T20:53:29+00:00

Patch series "mm: khugepaged cleanups and mTHP prerequisites", v4.

The following series contains cleanups and prerequisites for my work on
khugepaged mTHP support [1].  These have been separated out to ease
review.

The first patch in the series refactors the page fault folio to pte
mapping and follows a similar convention as defined by
map_anon_folio_pmd_(no)pf().  This not only cleans up the current
implementation of do_anonymous_page(), but will allow for reuse later in
the khugepaged mTHP implementation.

The second patch adds a small is_pmd_order() helper to check if an order
is the PMD order.  This check is open-coded in a number of places.  This
patch aims to clean this up and will be used more in the khugepaged mTHP
work.  The third patch also adds a small DEFINE for (HPAGE_PMD_NR - 1)
which is used often across the khugepaged code.

The fourth and fifth patch come from the khugepaged mTHP patchset [1]. 
These two patches include the rename of function prefixes, and the
unification of khugepaged and madvise_collapse via a new
collapse_single_pmd function.

Patch 1:     refactor do_anonymous_page into map_anon_folio_pte_(no)pf
Patch 2:     add is_pmd_order helper
Patch 3:     Add define for (HPAGE_PMD_NR - 1)
Patch 4:     Refactor/rename hpage_collapse
Patch 5:     Refactoring to combine madvise_collapse and khugepaged

A big thanks to everyone that has reviewed, tested, and participated in
the development process.


This patch (of 5):

The anonymous page fault handler in do_anonymous_page() open-codes the
sequence to map a newly allocated anonymous folio at the PTE level:

	- construct the PTE entry
	- add rmap
	- add to LRU
	- set the PTEs
	- update the MMU cache.

Introduce two helpers to consolidate this duplicated logic, mirroring the
existing map_anon_folio_pmd_nopf() pattern for PMD-level mappings:

map_anon_folio_pte_nopf(): constructs the PTE entry, takes folio
references, adds anon rmap and LRU.  This function also handles the
uffd_wp that can occur in the pf variant.  The future khugepaged mTHP code
calls this to handle mapping the new collapsed mTHP to its folio.

map_anon_folio_pte_pf(): extends the nopf variant to handle MM_ANONPAGES
counter updates, and mTHP fault allocation statistics for the page fault
path.

The zero-page read path in do_anonymous_page() is also untangled from the
shared setpte label, since it does not allocate a folio and should not
share the same mapping sequence as the write path.  We can now leave
nr_pages undeclared at the function intialization, and use the single page
update_mmu_cache function to handle the zero page update.

This refactoring will also help reduce code duplication between
mm/memory.c and mm/khugepaged.c, and provides a clean API for PTE-level
anonymous folio mapping that can be reused by future callers (like
khugpeaged mTHP support)

Link: https://lkml.kernel.org/r/20260325114022.444081-1-npache@redhat.com
Link: https://lkml.kernel.org/r/20260325114022.444081-2-npache@redhat.com
Link: https://lore.kernel.org/all/20260122192841.128719-1-npache@redhat.com
Signed-off-by: Nico Pache 
Suggested-by: Lorenzo Stoakes (Oracle) 
Reviewed-by: Lorenzo Stoakes (Oracle) 
Reviewed-by: Dev Jain 
Reviewed-by: Lance Yang 
Acked-by: David Hildenbrand (Arm) 
Cc: Alistair Popple 
Cc: Andrea Arcangeli 
Cc: Anshuman Khandual 
Cc: Baolin Wang 
Cc: Barry Song 
Cc: Brendan Jackman 
Cc: Byungchul Park 
Cc: Catalin Marinas 
Cc: David Rientjes 
Cc: Gregory Price 
Cc: "Huang, Ying" 
Cc: Hugh Dickins 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Johannes Weiner 
Cc: Jonathan Corbet 
Cc: Joshua Hahn 
Cc: Kefeng Wang 
Cc: Liam Howlett 
Cc: "Masami Hiramatsu (Google)" 
Cc: Mathieu Desnoyers 
Cc: Matthew Brost 
Cc: Matthew Wilcox (Oracle) 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Nanyong Sun 
Cc: Pedro Falcato 
Cc: Peter Xu 
Cc: Rafael Aquini 
Cc: Rakie Kim 
Cc: Randy Dunlap 
Cc: Ryan Roberts 
Cc: Shivank Garg 
Cc: Steven Rostedt 
Cc: Suren Baghdasaryan 
Cc: Takashi Iwai (SUSE) 
Cc: Thomas Hellström 
Cc: Usama Arif 
Cc: Vishal Moola (Oracle) 
Cc: Vlastimil Babka 
Cc: Wei Yang 
Cc: Will Deacon 
Cc: Yang Shi 
Cc: Zach O'Keefe 
Cc: Zi Yan 
Cc: Lorenzo Stoakes 
Signed-off-by: Andrew Morton

mm: rename VMA flag helpers to be more readable

2026-04-05T20:53:18+00:00

Patch series "mm: vma flag tweaks".

The ongoing work around introducing non-system word VMA flags has
introduced a number of helper functions and macros to make life easier
when working with these flags and to make conversions from the legacy use
of VM_xxx flags more straightforward.

This series improves these to reduce confusion as to what they do and to
improve consistency and readability.

Firstly the series renames vma_flags_test() to vma_flags_test_any() to
make it abundantly clear that this function tests whether any of the flags
are set (as opposed to vma_flags_test_all()).

It then renames vma_desc_test_flags() to vma_desc_test_any() for the same
reason.  Note that we drop the 'flags' suffix here, as
vma_desc_test_any_flags() would be cumbersome and 'test' implies a flag
test.

Similarly, we rename vma_test_all_flags() to vma_test_all() for
consistency.

Next, we have a couple of instances (erofs, zonefs) where we are now
testing for vma_desc_test_any(desc, VMA_SHARED_BIT) &&
vma_desc_test_any(desc, VMA_MAYWRITE_BIT).

This is silly, so this series introduces vma_desc_test_all() so these
callers can instead invoke vma_desc_test_all(desc, VMA_SHARED_BIT,
VMA_MAYWRITE_BIT).

We then observe that quite a few instances of vma_flags_test_any() and
vma_desc_test_any() are in fact only testing against a single flag.

Using the _any() variant here is just confusing - 'any' of single item
reads strangely and is liable to cause confusion.

So in these instances the series reintroduces vma_flags_test() and
vma_desc_test() as helpers which test against a single flag.

The fact that vma_flags_t is a struct and that vma_flag_t utilises sparse
to avoid confusion with vm_flags_t makes it impossible for a user to
misuse these helpers without it getting flagged somewhere.

The series also updates __mk_vma_flags() and functions invoked by it to
explicitly mark them always inline to match expectation and to be
consistent with other VMA flag helpers.

It also renames vma_flag_set() to vma_flags_set_flag() (a function only
used by __mk_vma_flags()) to be consistent with other VMA flag helpers.

Finally it updates the VMA tests for each of these changes, and introduces
explicit tests for vma_flags_test() and vma_desc_test() to assert that
they behave as expected.


This patch (of 6):

On reflection, it's confusing to have vma_flags_test() and
vma_desc_test_flags() test whether any comma-separated VMA flag bit is
set, while also having vma_flags_test_all() and vma_test_all_flags()
separately test whether all flags are set.

Firstly, rename vma_flags_test() to vma_flags_test_any() to eliminate this
confusion.

Secondly, since the VMA descriptor flag functions are becoming rather
cumbersome, prefer vma_desc_test*() to vma_desc_test_flags*(), and also
rename vma_desc_test_flags() to vma_desc_test_any().

Finally, rename vma_test_all_flags() to vma_test_all() to keep the
VMA-specific helper consistent with the VMA descriptor naming convention
and to help avoid confusion vs.  vma_flags_test_all().

While we're here, also update whitespace to be consistent in helper
functions.

Link: https://lkml.kernel.org/r/cover.1772704455.git.ljs@kernel.org
Link: https://lkml.kernel.org/r/0f9cb3c511c478344fac0b3b3b0300bb95be95e9.1772704455.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Suggested-by: Pedro Falcato 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Pedro Falcato 
Cc: Arnd Bergmann 
Cc: Babu Moger 
Cc: Baolin Wang 
Cc: Chao Yu 
Cc: Chatre, Reinette 
Cc: Chunhai Guo 
Cc: Damien Le Maol 
Cc: Dan Williams 
Cc: Dave Jiang 
Cc: Dave Martin 
Cc: Gao Xiang 
Cc: Greg Kroah-Hartman 
Cc: Hongbo Li 
Cc: Hugh Dickins 
Cc: James Morse 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jason Gunthorpe 
Cc: Jeffle Xu 
Cc: Johannes Thumshirn 
Cc: Konstantin Komarov 
Cc: Liam Howlett 
Cc: "Luck, Tony" 
Cc: Matthew Wilcox (Oracle) 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Muchun Song 
Cc: Naohiro Aota 
Cc: Oscar Salvador 
Cc: Sandeep Dhavale 
Cc: Suren Baghdasaryan 
Cc: Vishal Verma 
Cc: Vlastimil Babka 
Cc: Yue Hu 
Signed-off-by: Andrew Morton

mm/memory: support VM_MIXEDMAP in zap_special_vma_range()

2026-04-05T20:53:15+00:00

There is demand for also zapping page table entries by drivers in
VM_MIXEDMAP VMAs[1].

Nothing really speaks against supporting VM_MIXEDMAP for driver use.  We
just don't want arbitrary drivers to zap in ordinary (non-special) VMAs.

Link: https://lkml.kernel.org/r/20260227200848.114019-17-david@kernel.org
Link: https://lore.kernel.org/r/aYSKyr7StGpGKNqW@google.com [1]
Signed-off-by: David Hildenbrand (Arm) 
Reviewed-by: Lorenzo Stoakes (Oracle) 
Cc: Alexander Gordeev 
Cc: Alexei Starovoitov 
Cc: Alice Ryhl 
Cc: Andrii Nakryiko 
Cc: Andy Lutomirski 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnd Bergmann 
Cc: Arve 
Cc: "Borislav Petkov (AMD)" 
Cc: Carlos Llamas 
Cc: Christian Borntraeger 
Cc: Christian Brauner 
Cc: Claudio Imbrenda 
Cc: Daniel Borkman 
Cc: Dave Airlie 
Cc: David Ahern 
Cc: David Rientjes 
Cc: David S. Miller 
Cc: Dimitri Sivanich 
Cc: Eric Dumazet 
Cc: Gerald Schaefer 
Cc: Greg Kroah-Hartman 
Cc: Hartley Sweeten 
Cc: Heiko Carstens 
Cc: Ian Abbott 
Cc: Ingo Molnar 
Cc: Jakub Kacinski 
Cc: Jani Nikula 
Cc: Jann Horn 
Cc: Janosch Frank 
Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Jonas Lahtinen 
Cc: Leon Romanovsky 
Cc: Liam Howlett 
Cc: Madhavan Srinivasan 
Cc: Matthew Wilcox (Oracle) 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Miguel Ojeda 
Cc: Mike Rapoport 
Cc: Namhyung kim 
Cc: Neal Cardwell 
Cc: Paolo Abeni 
Cc: Pedro Falcato 
Cc: Peter Zijlstra 
Cc: Rodrigo Vivi 
Cc: Shakeel Butt 
Cc: Suren Baghdasaryan 
Cc: Todd Kjos 
Cc: Tvrtko Ursulin 
Cc: Vasily Gorbik 
Cc: Vincenzo Frascino 
Signed-off-by: Andrew Morton

mm: rename zap_vma_ptes() to zap_special_vma_range()

2026-04-05T20:53:15+00:00

zap_vma_ptes() is the only zapping function we export to modules.

It's essentially a wrapper around zap_vma_range(), however, with some
safety checks:
* That the passed range fits fully into the VMA
* That it's only used for VM_PFNMAP

We will add support for VM_MIXEDMAP next, so use the more-generic term
"special vma", although "special" is a bit overloaded.  Maybe we'll later
just support any VM_SPECIAL flag.

While at it, improve the kerneldoc.

Link: https://lkml.kernel.org/r/20260227200848.114019-16-david@kernel.org
Signed-off-by: David Hildenbrand (Arm) 
Acked-by: Leon Romanovsky 	[drivers/infiniband]
Reviewed-by: Lorenzo Stoakes (Oracle) 
Cc: Alexander Gordeev 
Cc: Alexei Starovoitov 
Cc: Alice Ryhl 
Cc: Andrii Nakryiko 
Cc: Andy Lutomirski 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnd Bergmann 
Cc: Arve 
Cc: "Borislav Petkov (AMD)" 
Cc: Carlos Llamas 
Cc: Christian Borntraeger 
Cc: Christian Brauner 
Cc: Claudio Imbrenda 
Cc: Daniel Borkman 
Cc: Dave Airlie 
Cc: David Ahern 
Cc: David Rientjes 
Cc: David S. Miller 
Cc: Dimitri Sivanich 
Cc: Eric Dumazet 
Cc: Gerald Schaefer 
Cc: Greg Kroah-Hartman 
Cc: Hartley Sweeten 
Cc: Heiko Carstens 
Cc: Ian Abbott 
Cc: Ingo Molnar 
Cc: Jakub Kacinski 
Cc: Jani Nikula 
Cc: Jann Horn 
Cc: Janosch Frank 
Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Jonas Lahtinen 
Cc: Liam Howlett 
Cc: Madhavan Srinivasan 
Cc: Matthew Wilcox (Oracle) 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Miguel Ojeda 
Cc: Mike Rapoport 
Cc: Namhyung kim 
Cc: Neal Cardwell 
Cc: Paolo Abeni 
Cc: Pedro Falcato 
Cc: Peter Zijlstra 
Cc: Rodrigo Vivi 
Cc: Shakeel Butt 
Cc: Suren Baghdasaryan 
Cc: Todd Kjos 
Cc: Tvrtko Ursulin 
Cc: Vasily Gorbik 
Cc: Vincenzo Frascino 
Signed-off-by: Andrew Morton