Linux MM 2026-05-08~10最新 Feature 分析报告

1. DAMON 随机数生成器性能优化：以无锁 PRNG 替代 get_random_u32_below()
2. zsmalloc per-CPU 延迟释放：异步批量释放加速 swap entry 回收
3. zsmalloc zs_free() 锁竞争优化：编码 class_idx 与缩小临界区
4. readahead 在 EOF 处禁止设置 PG_readahead 标记
5. 支持 zswap 后端的匿名大页换入
6. userfaultfd 实现 VM 虚拟机内存工作集追踪
7. dma-contiguous: 新增 Kconfig 选项为多 NUMA 节点自动设置 CMA
8. 按 NUMA 节点暴露 Balloon 页面统计
9. mm: 将零页设为只读以检测内核非法写入
10. 限定零页重映射仅在 underused THP 分裂时生效
11. selftests/cgroup: malloc 返回值检查
12. mm/shrinker: 修复 set_shrinker_bit() 中的越界读取
13. mm/filemap: 修复 page_cache_prev_miss() 无空洞时的返回值
14. zram: 修复 zram_writeback_endio 中的 use-after-free
15. x86/xen: 修复上下文切换中 lazy MMU 模式处理
16. mm/slub: 在 flush_rcu_sheaves_on_cache() 外围持有 cpus_read_lock

1. DAMON 随机数生成器性能优化：以无锁 PRNG 替代 get_random_u32_below()

系列：[PATCH v3] mm/damon: replace damon_rand() with a per-ctx lockless PRNG作者： Jiayuan Chen版本： v3（1p）

背景

DAMON（Data Access MONitor）通过周期性采样地址空间的随机页面来监控内存访问模式。在采样路径上，damon_rand() 函数被频繁调用，用于在每个 region 的地址范围内随机选取一个采样地址（sampling_addr）。原有的 damon_rand() 实现直接封装了内核的 get_random_u32_below()，是一个加密学强度的随机数生成器（CSPRNG），内部基于每 CPU 批处理熵池，周期性地用 ChaCha20 算法补充熵。每次调用需要执行 local_lock_irqsave() 和 local_unlock_irqrestore() 来保护该 per-CPU 熵池。

当 DAMON 配置了较高的 nr_regions 时（例如 20000+），kdamond 线程在每次采样迭代中需要对每个 region 调用一次 damon_rand()，导致 lock_acquire/local_lock 配对的开销以及 __get_random_u32_below() 自身的开销在性能剖析（perf profile）中占据了主导地位。

解决的问题

• kdamond CPU 开销过高：在高 nr_regions 配置下，加密学随机数生成器的锁开销成为性能瓶颈，kdamond CPU 占用高达约 72% 的单核资源。
• 安全随机数的不必要使用：DAMON 的 sampling_addr 仅用于选择 PTE accessed-bit 采样的探测点，不暴露给用户空间，不需要密码学强度的随机性。

如何做

本 patch 将 damon_rand() 的实现从加密学随机数生成器替换为基于 lfsr113（Linear Feedback Shift Register，一种线性 PRNG）的无锁伪随机数生成器。核心变化：

**PRNG 状态嵌入 damon_ctx**：在 struct damon_ctx 中新增 struct rnd_state rnd_state 字段。kdamond 是每个 ctx 的唯一消费者，因此不需要任何同步机制（无锁）。PRNG 在 damon_new_ctx() 中通过 get_random_u64() 获取密码学安全的种子初始化，之后所有调用完全在用户态级别完成。

范围映射：新的 damon_rand(ctx, l, r) 签名增加 ctx 参数以获取 PRNG 状态。对于跨度 span = r - l 不大于 U32_MAX 的常见情况，使用传统的 reciprocal multiplication 方法：l + (rnd * span) >> 32，与 get_random_u32_below() 所用方法一致。对于跨度超过 U32_MAX 的情况（仅在 64 位系统上可达），慢速路径将两个 32 位随机数组合为 64 位，然后使用 mul_u64_u64_shr() 进行 64 位范围映射。在 32 位系统上慢速路径是死代码，会被编译器消除。

调用者适配：damon_split_regions_of() 和相关的 kunit 测试函数签名均增加 ctx 参数以传递 PRNG 上下文。物理地址监控（paddr.c）和虚拟地址监控（vaddr.c）的采样准备函数均相应更新。

作者明确指出 lfsr113 是线性 PRNG，绝对不能用于任何安全敏感的场合。此处使用非加密 PRNG 是合适的，因为 DAMON 的采样地址不暴露给用户空间，仅用作 PTE accessed-bit 采样的探测点。

收益

kdamond CPU 使用率从单核的约 72% 降至约 50%，相当于节省了约 22 个百分点的 CPU 资源。该优化对低 nr_regions 配置也有正向收益，因为完全消除了 per-CPU CSPRNG 的 local_lock_irqsave/restore 开销。

2. zsmalloc per-CPU 延迟释放：异步批量释放加速 swap entry 回收

系列：[PATCH v3 00/04] mm/zsmalloc: per-cpu deferred free to accelerate swap entry release作者： Wenchao Hao, Barry Song版本： v3（4p）

背景

当进程的 VMA 中含有大量 swap entry 时，munmap（或进程退出）过程中的 swap 释放操作会非常昂贵。在 Android 系统的低内存终止（low-memory killer）场景中，当多个进程被同时终止以回收内存时，slot_free() 的耗时占到了释放 swap entry 总开销的 80% 以上。此前社区有两次尝试（Lei 和 Zhiguo）通过在 mm 核心层引入新线程来异步收集和释放 swap entry，方案设计本身相当复杂，未被合入。

当进程的匿名页（anon folios）和 swap entry 混合存在时，尽快回收 anon folios 可以帮助系统释放内存以满足新启动应用的需求。然而 swap 释放（涉及压缩内存的 zram/zswap 后端操作）如果阻塞了 anon folios 的释放，就会拖慢整体内存回收速度。swap 释放可以通过压缩内存逐步归还系统，但速率较慢。

解决的问题

• swap 释放阻塞 anon folios 回收：slot_free()（zram）和 zswap_entry_free()（zswap）在 munmap 热路径上执行，严重拖慢了被杀进程的内存回收速度。
• 无统一的延迟释放框架：zram 和 zswap 各自需要异步释放能力，但缺乏统一的基础设施。
• zram slot_free() 多次标志位写入开销：每次 slot_free() 中有 4 次独立的标志位清除操作，产生冗余的读-改-写周期。

如何做

本系列引入了一套基于回调（callback）的 zsmalloc 延迟释放框架，核心设计要点：

per-CPU 单页缓冲区：每个 CPU 拥有一个独立的单页缓冲区（struct zs_deferred_percpu），包含 buf 指针和 count 计数器。热路径（zs_free_deferred()）通过 push 回调将值写入当前 CPU 的缓冲区，仅需关闭抢占（get_cpu_ptr），无需任何锁或原子操作。zram 存储 u32 的 slot 索引（每页 1024 个条目），zswap 存储 unsigned long 的 entry 指针（每页 512 个条目）。

页池旋转机制：预分配 ZS_DEFERRED_POOL_SIZE（256KB / PAGE_SIZE）个页面构成页池。当缓冲区填满时，从页池获取空闲页面进行交换（swap），将满页面加入 deferred_drain_list 并排队到 WQ_UNBOUND 工作队列（workqueue）。如果页池为空，调用者回退到同步处理路径。

回调接口：通过 struct zs_deferred_ops 定义 push 和 drain 两个回调。push 负责写入缓冲区并返回三种状态：ZS_PUSH_OK（写入成功）、ZS_PUSH_FULL（缓冲区已满，值未入队）、ZS_PUSH_FULL_QUEUED（缓冲区已满，值已入队）。drain 在后台 worker 中执行批量释放：zram 的 drain 执行 slot_lock + slot_free + slot_unlock，zswap 的 drain 执行完整的 zswap_entry_free()（包括 lru_del、zs_free、memcg uncharge、cache_free 和统计更新）。

批量标志位清除：zram 的 slot_free() 中原有 4 次独立的 clear_slot_flag() 调用，分别清除 ZRAM_IDLE、ZRAM_INCOMPRESSIBLE、ZRAM_PP_SLOT 并重置压缩优先级。现合并为单次掩码写入：zram->table[index].attr.flags &= ~ZRAM_SLOT_FREE_CLEAR_MASK，减少冗余的读-改-写周期。

收益

测试平台：Raspberry Pi 4B, ARM64, 8GB RAM

Test 1: munmap 延迟，256MB swap-filled VMA（zram 后端）

Test 2: 不同大小的 munmap 延迟（zram，单进程）

Test 3: munmap 延迟，256MB swap-filled VMA（zswap 后端）

单进程场景加速最为显著（zram 达 7.17x、zswap 达 2.97x），因为释放操作完全从热路径卸载到了后台 worker。512MB 以上时加速比递减，因为页池容量固定（256KB 缓冲区对应约 256 个 zspage），大量 swap entry 导致频繁回退到同步路径。

3. zsmalloc zs_free() 锁竞争优化：编码 class_idx 与缩小临界区

系列：[PATCH 00/03] mm/zsmalloc: reduce lock contention in zs_free()作者： Wenchao Hao, Xueyuan Chen版本： v1（3p）

背景

在多进程并发执行 munmap 释放大量 swap entry 时，zsmalloc 的 zs_free() 函数是主要的性能瓶颈。锁竞争集中于两个层面：

1. pool->lock（读写锁）的缓存行颠簸：zs_free() 需要在 pool->lock 读锁保护下，通过 handle 逐步解析 handle->obj->PFN->zpdesc->zspage->class 链以获取 size class。虽然使用的是读锁，但 read_lock/read_unlock 的原子操作会在多个 CPU 同时访问同一缓存行时产生严重的缓存一致性流量（cacheline bouncing），多核并发时开销急剧上升。

2. class->lock 横跨页面释放导致锁嵌套放大：原有的 zs_free() 在持有 class->lock（自旋锁）期间调用 free_zspage()，而 free_zspage() 最终需要获取 buddy allocator 的 zone->lock。在高内存压力下，zone->lock 竞争激烈时，持有 class->lock 的 CPU 会阻塞等待 zone->lock，从而阻塞所有等待同一 class->lock 的其他 CPU。

解决的问题

• pool->lock 读锁竞争：多核并发 zs_free() 时的 read_lock 原子操作在高并发下成为瓶颈。
• class->lock 临界区过长：页面释放的 zone->lock 嵌套在 class->lock 内，导致锁竞争传播放大。
• 32 位系统的位宽限制：无法简单地在 obj 值中编码 class_idx。

如何做

本系列围绕三个独立的技术维度来解决上述锁竞争问题，三者可叠加但不互相依赖（64 位优化受架构条件限制，class->lock 拆分对所有架构生效）。

（一）obj 编码方案：将 class_idx 存入 obj 值中

这是消除 pool->lock 的前提条件。作者指出原有 64 位系统的 OBJ_INDEX_BITS 严重过剩——"OBJ_INDEX_BITS is over-provisioned on 64-bit systems"，以 arm64 默认 chain_size=8 为例，OBJ_INDEX_BITS=24，但 obj_idx 只需 10 位。本方案从实际的 size class 数量和最大 obj 计数出发，动态计算所需位数 OBJ_CLASS_BITS_NEEDED 和 OBJ_IDX_BITS_NEEDED，将 obj 的位布局从 [PFN | obj_idx] 改为 [PFN | class_idx | obj_idx]，并通过 static_assert 在编译期验证三个字段之和不超过 BITS_PER_LONG，确保在所有 64 位架构（包括 riscv64 Sv57 的 44 位 PFN 和 powerpc64 64K 页的 257 class）都能容纳。

关键不变量在于："class_idx is invariant across page migration (only PFN changes)"，迁移只改写 PFN 字段，class_idx 和 obj_idx 始终保持不变。因此无需加锁即可从 obj 值中提取 class_idx——无锁读取总是得到合法的 class_idx。location_to_obj() 接口同步扩展，传入 class_idx 参数；obj_malloc() 和 zs_page_migrate() 分别在分配和迁移路径上向 obj 编码 class_idx。该特性由 ZS_OBJ_CLASS_IDX 宏控制，仅在 BITS_PER_LONG >= 64 时启用，32 位系统位宽不足自动回退到原有布局。

（二）消除 pool->lock：在 zs_free() 中实现无锁 class 查找

有了 obj 编码中硬编码的 class_idx 之后，zs_free() 无需再遍历 handle->obj->PFN->zpdesc->zspage->class 链，也无需持有 pool->lock。如作者所述："64-bit aligned reads are atomic, so a lockless read of the handle always yields a valid class_idx"。具体流程：首先无锁读取 handle 得到 obj 值，通过 obj_to_class_idx() 提取 class_idx 并定位到正确 size_class，随后获取 class->lock。在 class->lock 保护下，再次读取 handle 以获取稳定的 PFN——"migration also acquires class->lock, so the obj value is now stable and the PFN is valid"——因为页面迁移同样要获取同一 class->lock，在锁内读取的 PFN 必然有效。由此消除了 zs_free() 与页面迁移/压缩之间的读写锁竞争，彻底避免了多核并发下 read_lock/read_unlock 原子操作对 rwlock 同一缓存行造成的 cacheline bouncing。

该优化仍然由 ZS_OBJ_CLASS_IDX 控制，仅在 64 位系统生效；32 位系统保持原有 pool->lock 路径。

（三）拆分 class->lock 临界区：将 zspage 释放移到锁外

即使消除了 pool->lock，class->lock 本身也因嵌套 zone->lock 而导致竞争传播。作者提道："freeing pages back to the buddy allocator requires acquiring the zone lock. Under heavy memory pressure, zone lock contention can be severe. When this happens, the CPU holding the class->lock will stall waiting for the zone lock, thereby blocking all other CPUs attempting to acquire the same class->lock."。解决方案是将页面释放动作拆分为 class->lock 内的记账操作和锁外的 buddy allocator 交互。在 class->lock 内，从 zspage 链表移除、扣除 ZS_OBJS_ALLOCATED 计数并标记 zspage_to_free；释放 class->lock 之后才调用 __free_zspage_lockless() 执行实际的 free_zpdesc() 和 buddy 页面归还，pages_allocated 的原子递减也移到锁外完成。这样即使 zone->lock 竞争激烈，持有 class->lock 的 CPU 不会阻塞在内，同一 class 的其他 CPU 得以继续并发释放。此优化对所有架构（包括 32 位）均生效。

收益

测试环境：每进程独立 mmap 256MB，写入数据，madvise MADV_PAGEOUT 换出到 zram（lzo-rle），然后并发 munmap。

Raspberry Pi 4B（4 核 ARM64 Cortex-A72）

x86（20 核 Intel i7-12700，16 并发进程）

单进程场景改善有限（仅受益于 class->lock 临界区缩小）。多进程场景加速显著（4 进程达 1.83x），因为消除了 pool->lock 读锁在多核间的缓存行颠簸。该优化与延迟释放方案（Feature 2）可以叠加使用，获得更大的综合收益。Patch 1-2 仅在 64 位系统生效，Patch 3 对所有架构均有收益。

4. readahead 在 EOF 处禁止设置 PG_readahead 标记

系列：[PATCH] mm/readahead: no PG_readahead on EOF作者： Frederick Mayle版本： 单 patch

背景

Linux 的预读（readahead）机制通过 PG_readahead 标记来驱动异步预读：当内核读取到一个带有该标记的 page 时，会触发下一轮异步预读。然而，该标记的语义隐含了一个假设——文件后面还有更多数据可供预读。当预读窗口已经覆盖到文件末尾（EOF）时，这个假设不再成立。此外，对于 mmap 文件 IO，PG_readahead 标记还会影响 fault-around 路径的行为：do_fault_around 调用 filemap_map_pages，而 next_uptodate_folio 会跳过所有设置了 PG_readahead 的页面，导致本可以被 fault-around 一并映射的页面被遗漏，产生额外的 minor fault。

解决的问题

• 预读到达 EOF 后，PG_readahead 标记会触发一次几乎必然是空操作的异步预读，浪费 CPU。
• 对于 mmap 文件 IO，EOF 页上的 PG_readahead 标记阻止了 fault-around 优化，导致无关的额外 minor fault。

如何做

核心思路是在两个预读入口函数中检测"已读到文件末尾"这个条件，并在该条件下禁止设置 readahead 标记。

在 do_page_cache_ra() 中，原有的逻辑是当 nr_to_read > end_index - index 时将 nr_to_read 截断为 end_index - index + 1。该 patch 在截断的同时将 lookahead_size 设为 0，这样 page_cache_ra_unbounded() 在设置 PG_readahead 标记时使用的 lookahead 窗口为零，即不会在任何 page 上设置该标记。

在 page_cache_ra_order() 中，原有的逻辑将 EOF 作为上限之一来限制预读范围，但 readahead 标记位（mark）仍按正常窗口计算。该 patch 改为：当上限由文件大小决定（而非预读窗口大小决定）时，将 mark 设为 ULONG_MAX，使得 folio_test_readahead() 永远不会被触发。

收益

作者未提供性能数据。从代码逻辑推断：对于顺序读文件的场景，该改动避免了 EOF 处一次无意义的 page_cache_ra_unbounded 调用；对于 mmap 文件 IO，避免了因 PG_readahead 被跳过而导致的额外 minor fault，fault-around 可以将相邻页面一并映射，减少缺页中断次数。

5. 支持 zswap 后端的匿名大页换入

系列：[RFC PATCH 0/5] mm: support zswap-backed anonymous large folio swapin作者： fujunjie版本： RFC（5p）

背景

Linux v6.8 之后已经支持匿名大页（anonymous large folio）换出到 zswap：每个 base page 作为独立的 zswap entry 存储。然而换入路径一直是 order-0 的——zswap_load() 直接拒绝 large folio，alloc_swap_folio() 中也有 zswap_never_enabled() 检查，一旦 zswap 曾被启用过，所有匿名大页换入都被迫降级为 4KB。这导致在广泛使用 zswap 的系统中（如 Android、云环境），mTHP 换入的收益完全无法获得。该 RFC 作为第一步，保守地只支持全 zswap 后端或全磁盘后端的大页换入，混合后端仍回退到 order-0。

解决的问题

• zswap 启用后，匿名大页换入被完全禁用，即使在 zswap 中所有 subpage 都存在的情况下也只能逐个 4KB 换入，失去了大页减少 TLB miss、减少缺页次数的优势。
• 混合后端（部分在 zswap、部分在磁盘）的大页换入处理复杂，需要先建立正确的 fallback 路径。

如何做

本 RFC 系列围绕四个独立的技术维度实现 zswap 后端的匿名大页换入支持，遵循保守原则——优先覆盖全 zswap 范围，混合后端回退到 order-0，暂不涉及 shmem。

（一）逐页偏移解压：让 zswap_decompress() 支持任意 base page 偏移

zswap 换出时已将大页的每个 base page 存储为独立的 zswap entry，但换入端的 zswap_decompress() 始终写入 folio 的偏移 0 位置，只能服务于 order-0 场景。如作者所述："That is sufficient while zswap only loads order-0 folios, but large folio swapin needs to fill each base page from its own zswap entry."。本方案为 zswap_decompress() 增加 index 参数，由调用者传入 base page 在大页中的位置索引。在函数内部，kmap_local_folio() 和 sg_set_folio() 的偏移量均基于 index * PAGE_SIZE 计算，确保每个 zswap entry 的解压数据被写入 folio 中对应的 base page 位置。现有调用者（zswap_writeback_entry() 和 order-0 的 zswap_load()）传入 index=0，行为不变。

（二）后端一致性检测：用 zswap_entry_batch() 辨识全 zswap / 全磁盘 / 混合范围

大页换入必须知道连续 swap 范围的每个 slot 是否一致地由同一后端支持——"A range that is partly in zswap and partly on disk cannot be read by the existing whole-folio swap_read_folio() backend selection."。新增的 zswap_entry_batch() 函数从起始 swap entry 开始，依次查询每个 slot 的 zswap xarray 是否存在，返回首个异构点之前的连续同构 slot 数量，并可返回起始 slot 的 zswap 存在状态。CONFIG_ZSWAP=n 的 stub 实现报告整个范围都不在 zswap 中。

借助此检测，大页换入路径将 swap 范围区分为三种情形："the whole range is absent from zswap and should fall through to the disk backend, the whole range is present and can be decompressed one base page at a time, or the range is mixed and must be treated as an invalid large-folio backend selection。"

（三）大页加载与回退：逐页解压 + 插入竞态重试

zswap_load() 的核心逻辑被重写为适用于大页的逐页处理流程。在通过 zswap_entry_batch() 确认整个范围均在 zswap 后，对每个 base page 依次执行：从对应 slot 的 xarray 提取 zswap entry → 调用 zswap_decompress(entry, folio, index) 解压到 folio 的对齐偏移 → 解压失败则整体回退。全部成功后将 folio 标记为 uptodate 和 dirty，并逐页从 xarray 中擦除每个 zswap entry（"the swapcache folio becomes authoritative"），同时按 base page 数量统计 ZSWPIN 事件、按大页粒度统计一次 mTHP swpin 计数。

此外，同步换入路径引入 swapin_synchronous_folio() 封装：当大页无法插入 swap cache（插入竞态或后端 recheck 失败），记录 mTHP swpin fallback 后丢弃大页分配，自动重试 order-0 换入——"folio is charged, so NULL means the large folio could not be inserted and needs order-0 fallback"。

（四）策略限制移除：取消 zswap_never_enabled() 的匿名大页禁令

前两步完成后，大页换入的内核已有能力在调用路径早期检测混合范围并安全回退。作者指出："With mixed zswap ranges rejected and the insertion-race fallback in place, remove the blanket zswap_never_enabled() fallback from the anonymous swapin path so all-zswap and all-disk anonymous ranges can use mTHP swapin."。具体变更包括：在 can_swapin_thp() 中加入 zswap_entry_batch() 调用，与现有的 zeromap 和 swapcache 检测并列为大页可行性判断条件；从 alloc_swap_folio() 中删除 !zswap_never_enabled() 的 fallback 分支；在 swap_cache_add_folio() 插入大页之前，于 swap cluster lock 保护下对后端一致性做最终 recheck——插入前若发现范围变为混合（可能因并发 writeback 将部分 slot 写入磁盘），返回 -EAGAIN 触发回退。shmem 路径保持原有的 zswap fallback 行为，不在本 RFC 范围内。

收益

测试环境：QEMU/KVM，CONFIG_ZSWAP=y, CONFIG_ZRAM=y, CONFIG_MEMCG=y, CONFIG_THP_SWAP=y。

该 RFC 验证了全 zswap 大页换入的正确性和混合后端的正确回退行为。作者计划在后续工作中探索混合后端的全大页换入支持。

6. userfaultfd 实现 VM 虚拟机内存工作集追踪

系列：[PATCH v2 00/14] userfaultfd: working set tracking for VM guest memory作者： Kiryl Shutsemau版本： v2（14p）

背景

虚拟机管理器（Virtual Machine Manager, VMM）管理客户机内存时需要一种高效手段来追踪哪些页面仍被访问（working-set tracking），以便将冷页面（cold pages）安全驱逐到分层存储（tiered storage）或远端存储，并在再次访问时按需取回。现有的 UFFDIO_REGISTER_MODE_WP（Write-Protection）只能拦截写访问，无法追踪读访问，因此无法准确判断完整的 working set。NUMA balancing 使用 PAGE_NONE（protnone）机制实现了访问拦截，userfaultfd 已有 UFFDIO_WRITEPROTECT 基础设施，但缺少将二者结合用于全读写保护的产品级接口。

解决的问题

• 现有 userfaultfd WP 模式只能捕获写访问，无法追踪读访问，导致 working set 检测不完整
• 缺乏一个统一的、跨 anon/shmem/hugetlbfs 后端的读写保护追踪原语
• VMM 需要既能批量异步检测访问模式（低开销），又能在驱逐阶段同步拦截竞争条件（race-free eviction）

如何做

本系列在 userfaultfd 框架内新增 RWP（Read-Write Protection） 模式，核心技术是利用 PAGE_NONE + uffd PTE 位组合做全访问拦截。

架构设计： 复用 NUMA balancing 的 protnone 机制（CONFIG_ARCH_HAS_PTE_PROTNONE），将 PTE 设为 PAGE_NONE 使得 CPU 对任何访问（读/写）都触发 page fault。同时在 PTE 上设置 uffd 位（原本由 VM_UFFD_WP 独占的 _PAGE_UFFD），用于区分 RWP fault 和普通 mprotect(PROT_NONE) 或 NUMA hinting fault。VM_UFFD_WP 和 VM_UFFD_RWP 在同一 VMA 上互斥，因此同一个 PTE bit 在不同 VMA flag 语义下分别表示 WP 或 RWP。

核心接口：

• **UFFDIO_REGISTER_MODE_RWP**：注册 VMA 进入 RWP 追踪模式，设置 VM_UFFD_RWP VMA flag。通过 CONFIG_USERFAULTFD_RWP（依赖 64BIT + ARCH_HAS_PTE_PROTNONE + HAVE_ARCH_USERFAULTFD_WP）编译控制。
• **UFFDIO_RWPROTECT**：双向保护 ioctl。设置 UFFDIO_RWPROTECT_MODE_RWP 时调用 change_protection(MM_CP_UFFD_RWP)，将已存在的 PTEs 改为 PAGE_NONE 并设 uffd 位；清除 MODE_RWP 时调用 change_protection(MM_CP_UFFD_RWP_RESOLVE) 恢复原始权限。
• **UFFD_FEATURE_RWP_ASYNC**：异步模式。fault 发生时内核原地自动恢复 PTE 权限（do_uffd_rwp() / do_huge_pmd_uffd_rwp()），faulting 线程不阻塞，不向用户态发送消息。通过 PAGEMAP_SCAN 的 PAGE_IS_ACCESSED 标志（bit 9）反向查询：uffd 位仍置位的页即未被重新访问。
• **UFFDIO_SET_MODE**：运行时在 sync/async 间切换，无需重新注册 userfaultfd。内部通过 mmap_write_lock() + vma_start_write() drain 所有运行中的 fault handler，然后 WRITE_ONCE(ctx->features, ...) 原子切换模式。切换至 async 时唤醒所有 pendings 的 sync 等待者。

Fault 路径修改：handle_pte_fault() 中，protnone + vma_accessible 的 PTE 先通过 userfaultfd_pte_rwp(vma, pte) 判断是否为 RWP 页，若是则路由到 do_uffd_rwp()。同理 __handle_mm_fault() 的 PMD 级和 hugetlb_fault() 的 hugetlb 级均增加对应的 RWP 分支。

marker 保留： 在 swap out、migration、fork、mremap、UFFDIO_MOVE、hugetlb copy 等 PTE 重写路径中保留 RWP marker（protnone + uffd 位），确保保护状态不被意外丢失。

收益

作者未提供性能数据。从代码逻辑推断的预期收益：

• VMM 可获得精确的 guest 全访问（读+写）working set 画像，相比仅有写拦截的 WP 模式大幅提升冷热识别准确度
• async 模式下检测零开销：不产生用户态消息、不阻塞 vCPU 线程，仅通过 PAGEMAP_SCAN 后验统计
• UFFDIO_SET_MODE 使得 VMM 能在检测期用 async（低开销）、驱逐期用 sync（零竞争窗口），无需重新注册或重建页表，降低了操作延迟
• 跨 anon/shmem/hugetlbfs 统一语义，VMM 无需为不同后端写三套代码
• 适用范围：所有 64-bit 架构（x86, arm64, riscv, s390, loongarch, powerpc）只要支持 protnone 和 uffd-wp 即可启用

7. dma-contiguous: 新增 Kconfig 选项为多 NUMA 节点自动设置 CMA

系列：[PATCH v5] dma-contiguous: add kconfig option to setup numa cma area if not configured explicitly作者： Feng Tang版本： v5（1p）

背景

在一台多 NUMA 节点的 arm64 服务器上，当 IOMMU 禁用时，dma_alloc_coherent() 始终从 node 0 分配 DMA 内存，即使设备挂载在其他 NUMA 节点。原因是系统只有一个默认的 64MB CMA 区域（Contiguous Memory Allocator），位于 node 0，内核会优先从中分配。而当 IOMMU 启用时，同样的 API 却能获取本地 DMA 内存。Robin Murphy 建议配置 per-NUMA CMA 或禁用 CMA 来解决问题。但对于缺乏内核知识的用户，某些架构（非 x86，x86 默认 CONFIG_CMA_SIZE_MBYTES=0）默认启用 CMA 导致问题静默发生。

解决的问题

• 多 NUMA 节点系统中，未显式配置 per-numa CMA 时，非 node 0 的设备无法获得本地 DMA 内存，导致 DMA 性能下降
• 普通用户难以意识到需要手动配置 numa_cma=<node>:size 或 cma_pernuma=<size> 内核参数

如何做

新增 CONFIG_CMA_SIZE_PERNUMA 布尔配置项（依赖 CONFIG_DMA_NUMA_CMA，默认 y）。启动时，在 dma_numa_cma_reserve() 中检查：

1. 用户是否已通过命令行显式配置——若已配置，走原有逻辑。
2. 若未显式配置且 dma_contiguous_default_area 存在，则遍历每个 NUMA 节点：如果节点 ID 不等于默认 CMA 所在节点（通过新增的 cma_get_nid() 获取），则为该节点分配与默认 CMA 相同大小的 CMA 区域；如果等于，则直接复用默认 CMA。

新增 cma_get_nid() 辅助函数（mm/cma.c），返回 cma->nid。同时在 __cma_declare_contiguous_nid() 中，当 nid == NUMA_NO_NODE 且 CONFIG_NUMA 启用时，通过 early_pfn_to_nid() 自动推断 CMA 区域的 NUMA 节点归属。

单 NUMA 节点系统行为保持不变（无需额外分配内存）。用户仍可通过 numa_cma=0:0 或 cma_pernuma=0 禁用此功能。

收益

作者未提供性能数据。从代码逻辑推断：多 NUMA 节点系统上，未进行任何 CMA 配置的情况下，设备能自动获得本地节点的 CMA 区域，显著改善 DMA 访问的局部性（latency 和 bandwidth）。用户无需手动配置内核命令行参数即可获得优化的 DMA 布局，降低了部署门槛。

8. 按 NUMA 节点暴露 Balloon 页面统计

系列：[PATCH v3] per-node balloon pages exposure作者： Hao Ge版本： v3（1p）

背景

commit 835de37603ef（"meminfo: add a per node counter for balloon drivers"）新增了 NR_BALLOON_PAGES 统计计数器并将其暴露于 /proc/meminfo。该计数器已按 NUMA 节点追踪，但 /sys/devices/system/node/nodeX/meminfo 中并未同步更新。如作者所述："Commit 835de37603ef ("meminfo: add a per node counter for balloon drivers") added NR_BALLOON_PAGES and exposed it in /proc/meminfo. However, the per-node view at /sys/devices/system/node/nodeX/meminfo was not updated, even though the counter is already tracked per-node."

解决的问题

• /sys/devices/system/node/nodeX/meminfo 缺少 Balloon 字段，而 /proc/meminfo 中有
• 用户无法通过标准 sysfs 接口按 NUMA 节点查看 balloon 内存占用

正如作者指出的，用户本应可以 "see balloon usage per NUMA node without having to parse the raw vmstat file"，但当前接口缺少这一能力。

如何做

在 drivers/base/node.c 的 node_read_meminfo() 函数中，新增一行 "Node %d Balloon: %8lu kB\n" 格式字符串及对应的 node_page_state(pgdat, NR_BALLOON_PAGES) 参数。v2 版本将 Balloon 字段放置在 Unaccepted 之后（经 David Hildenbrand 建议），v3 版本在 rebase 到 commit 2232ba9c7931（"mm: add gpu active/reclaim per-node stat counters (v2)"）后，进一步精确对齐排序：将 Balloon 放在 Unaccepted 和 GPUActive 之间，确保与 /proc/meminfo 的字段顺序完全一致。改动仅 2 行插入。

收益

作者未提供性能数据。纯暴露性改动：将已存在的 per-node NR_BALLOON_PAGES 计数器暴露到 /sys/devices/system/node/nodeX/meminfo，用户无需解析原始 vmstat 文件，即可按 NUMA 节点直接查看 balloon 驱动占用的内存量，使 sysfs 接口与 /proc/meminfo 在字段完整性上保持一致。无性能影响。

9. mm: 将零页设为只读以检测内核非法写入

系列：[PATCH] mm: make zeropage read-only作者：Jann Horn版本：v1（1p）

背景

内核的 empty_zero_page 是一个全局共享的 4K 全零页面，用于匿名映射中零填充页的 COW 源，任何对该页内容的修改都属于语义错误。作者这样阐述动机："Put the zeropage in the read-only data section - nothing should ever change its contents." 该页之前存放在 .bss..page_aligned 段，属于可写数据段。为实现只读放置，需要新引入 .rodata..page_aligned 段，与已有的 .data..page_aligned 和 .bss..page_aligned 段镜像对应，如作者所述："Set up a new section .rodata..page_aligned to mirror the existing .data..page_aligned and .bss..page_aligned sections."

解决的问题

近年来多次出现同类型安全漏洞：内核通过 GUP 或 splice 以只读语义获取用户空间页面的引用，但随后丢失了对只读语义的追踪并错误地写入了这些页面。作者指出："There have been several security bugs where the kernel grabs references to pages from some userspace-specified source, via GUP or splice, with read-only semantics; and then later on, the kernel loses track of the pages' read-only semantics and writes into them. I have seen such bugs in out-of-tree GPU drivers before, and recently upstream Linux bugs of this shape have been discovered as well."

这类 bug 难以被 fuzzer 发现，因为内核没有直接机制检测此类语义违反。作者进一步说明："One problem with these bugs is that fuzzers and such will have a hard time noticing them, because the kernel has no mechanism to directly detect that such a bug has occurred. It would be nice if we had debug infrastructure to keep track of whether file pages are supposed to be writable, or such; but for now, the easiest way to make these bugs detectable in at least some cases is to make sure that writing the 4K zeropage is mapped as read-only in the kernel, so that attempting to write into it immediately crashes (unless the write happens through a vmap mapping or such)."

如何做