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

On Wed, 15 Jul 2026 11:18:33 +0000 Dev Jain <dev.jain@arm.com> wrote:

> 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.

Thanks, I'll await reviewer input on this.

Sashiko might have found a pre-existing issue:
	https://sashiko.dev/#/patchset/20260715111839.1667914-1-dev.jain@arm.com

On 16/07/26 12:28 am, Andrew Morton wrote:
> On Wed, 15 Jul 2026 11:18:33 +0000 Dev Jain <dev.jain@arm.com> wrote:
> 
>> 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.
> 
> Thanks, I'll await reviewer input on this.
> 
> Sashiko might have found a pre-existing issue:
> 	https://sashiko.dev/#/patchset/20260715111839.1667914-1-dev.jain@arm.com

That was unexpected from Sashiko.

"When a large folio registered with uffd-wp is unmapped via
try_to_unmap_one(), folio_unmap_pte_batch() batches and clears multiple PTEs."

At patch 2, there is no batching support yet for uffd-wp folios.