[PATCH 0/3] Batch unmap of uffd-wp file folios

[Dev Jain <dev.jain@arm.com>]

Currently, batched unmapping is supported if:

1) folio is a file folio, not belonging to uffd-wp VMA
2) folio is anonymous and not swapbacked (lazyfree), not belonging to
   uffd-wp VMA

So the cases which are not supported are

1) folio belonging to uffd-wp VMA
2) folio is anonymous and swapbacked

It is easy to see that this adds a lot of cognitive load while reading
try_to_unmap_one - we need to remember throughout whether nr_pages == 1
or > 1.

The uffd-wp handling in try_to_unmap_one is regarding preserving the
uffd-wp state for file folios via pte_install_uffd_wp_if_needed (for anon
folio, we handle that while constructing the swap pte).

Stop special casing on uffd-wp VMAs by simply adding batching support
to pte_install_uffd_wp_if_needed.

---
This is a split from:
https://lore.kernel.org/all/20260526063635.61721-1-dev.jain@arm.com/

mm-selftests pass.

I have based this on mm-new since my try_to_unmap_one refactoring changes
weren't there in mm-unstable yet. But I suspect this series wouldn't
have conflicted there, or conflicted trivially.

mm-new currently has Kiryl's uffd-rwp series, which confuses me about
the terminology followed by my patchset (and the existing functions):
shall I call it uffd-wp bit or uffd bit?

Dev Jain (3):
  mm/memory: move pte_install_uffd_wp_if_needed() into memory.c
  mm/memory: batch set uffd-wp markers during zapping
  mm/rmap: batch unmap file folios belonging to uffd-wp VMAs

 include/linux/mm.h        |  4 ++
 include/linux/mm_inline.h | 53 ------------------------
 mm/memory.c               | 84 +++++++++++++++++++++++++++++----------
 mm/rmap.c                 |  6 +--
 4 files changed, 70 insertions(+), 77 deletions(-)

-- 
2.43.0