背景
rmap 的批量 unmap 此前已覆盖文件 large folio，但 uffd-wp VMA 被排除在外。uffd-wp 是 userfaultfd 的写保护：unmap 时要把 present PTE 换成 uffd-wp marker 留住写保护状态，而标记安装 helper 只会逐 PTE 处理，批量路径遇到这种 VMA 只能整体退回。
uffd-wp VMA 被排除在批量 unmap 之外
┌──────────────────────────────────────┐
│ 文件 large folio 已支持批量 unmap │
└──────────────────┬───────────────────┘
▼
┌──────────────────────────────────────┐
│ uffd-wp VMA 需保留写保护标记，也只能 │
│ 逐 PTE 处理 │
└──────────────────┬───────────────────┘
▼
┌──────────────────────────────────────┐
│ 批量路径遇到它就退回逐 PTE │
└──────────────────────────────────────┘
这个排除还有附带成本：try_to_unmap_one() 里到处要记着 nr_pages 是 1 还是大于 1，代码阅读负担不小。
问题
- uffd-wp VMA 的文件 folio 被排除在批量 unmap 之外
- zap 路径的 uffd-wp marker 同样只能逐 PTE 设置
- try_to_unmap_one() 里的 nr_pages 特判增加认知负担
方案
给 uffd-wp 标记安装加批量支持，再把两条路径放开。
标记安装的批量化先落在 zap 路径：helper 改名 cond_install_uffd_wp_ptes() 并支持批量。正确性由批量来源保证：nr 由 folio_pte_batch() 或 swap_pte_batch() 算出，意味着这批 PTE 同属一类 VMA、同享 wp 状态，且 marker 支持与否与参数无关。实现上用 set_pte_at() 循环而非 set_ptes()，后者处理不了 nr_pages 大于 1 的 nonpresent 到 nonpresent 转换。helper 本身体量已超出内联头文件的合适尺寸，顺带从 mm_inline.h 挪进 memory.c。
标记安装批量化后放开 uffd-wp
┌───────────────────────────────────────┐
│ zap 与 unmap 的 uffd-wp 标记安装支持 │
│ 批量 │
└───────────────────┬───────────────────┘
▼
┌───────────────────────────────────────┐
│ uffd-wp VMA 的文件 folio 进批量 unmap │
└───────────────────┬───────────────────┘
▼
┌───────────────────────────────────────┐
│ marker PTE 无 PFN，walk 会跳过，不做 │
│ 重复处理 │
└───────────────────────────────────────┘
rmap 一侧随之放开：folio_unmap_pte_batch() 允许批量处理 uffd-wp VMA 的文件 folio。文件 folio 带 uffd-wp 位时，unmap 把 present PTE 转成 marker，同一段范围不能在 try_to_unmap_one() 循环里被重复处理。这个保证由 page_vma_mapped_walk 给出：check_pte() 只对 [pfn, pfn + nr_pages) 内确有 PFN 映射的 PTE 返回真，marker PTE 底下没有 PFN，walk 自动跳过已转换的范围，直到遇见下一个 present 项。
收益
作者未提供性能数据，从代码逻辑推断的预期收益：
- uffd-wp VMA 的文件 large folio 进入批量 unmap，rmap 扫描效率对齐普通文件 folio
- zap 路径批量设置 marker，大批量 zapping 收益
- try_to_unmap_one() 不再按 nr_pages 特判 uffd-wp，逻辑变直