目录

1. BPF JIT 程序的 KASAN 内存安全检测支持
2. process_mrelease 加速回收与自动杀进程支持
3. 移除不支持 large folio 的文件系统的只读 THP 支持
4. DAMON kdamond 异常终止后线程状态参数未重置
5. blk-cgroup writeback 释放路径中的 use-after-free
6. vmalloc shrinker 路径缺少 vmap_purge_lock 导致并发竞态
7. Dynamic Housekeeping Management (DHM) via CPUSets
8. liveupdate: 修复模块卸载与反注册 API
9. folio_unmap_invalidate() 中的 use-after-free 修复
10. 按 NUMA 节点拆分文件 i_mmap 反向映射树
11. SLUB 延迟 freelist 构建优化批量分配
12. 不可恢复内存故障时立即 panic 选项

1. BPF JIT 程序的 KASAN 内存安全检测支持

系列：[PATCH RFC bpf-next 0/8] bpf: add support for KASAN checks in JITed programs作者： Alexis Lothore (eBPF Foundation, Bootlin)版本： RFC（8个patch）

背景

KASAN（Kernel Address Sanitizer）是内核中用于检测内存管理错误的动态分析工具，其原理是保留一部分"影子内存"（shadow memory）来映射和监控其余内存，在编译期对每条内存访问指令插桩（instrument），调用 ASAN 检查函数来分析影子内存中对应位，发现非法访问时触发详细报告。然而，BPF 程序在加载时通过 JIT 编译器从 BPF 字节码翻译为本地机器码，这一过程发生在运行时而非编译期，因此 KASAN 的编译期插桩机制完全无法覆盖 JIT 生成的代码。这意味着 BPF 程序中的 use-after-free、out-of-bounds 等内存安全缺陷无法被 KASAN 捕获，形成了内核内存安全检测的盲区。

解决的问题

• BPF JIT 生成的本地代码绕过了 KASAN 编译期插桩，无法检测 use-after-free 和 out-of-bounds 等内存错误
• 缺乏 BPF 程序运行时内存安全检测手段，调试 BPF 程序中的内存错误困难
• KASAN 的核心检查函数 __asan_{load,store}X 此前仅在 KASAN 内部头文件中声明，外部子系统无法调用

如何做

整体方案的核心思路是在 JIT 编译阶段复刻 KASAN 的编译期插桩逻辑：由 JIT 编译器在运行时识别需要监控的内存访问指令，并在其前面插入对应的 KASAN 检查调用。

首先，Patch 1 将 __asan_load1/store1 到 __asan_load8/store8 等函数声明从 mm/kasan/kasan.h 内部头文件移至公共头文件 include/linux/kasan.h，使 BPF JIT 编译器能合法调用这些检查函数。

其次，Patch 2 在 BPF verifier 层面增加栈访问标记机制。在 bpf_insn_aux_data 结构体中新增 accesses_stack 布尔字段，verifier 在 check_mem_access() 中检测到栈访问时调用 mark_insn_accesses_stack() 进行标记，并提供 bpf_insn_accesses_stack() 查询接口供 JIT 编译器使用。这是因为 BPF 程序栈已有页面守护（page guards）保护，无需重复插桩，且栈上变量的 red zone 插入需要更多上下文信息，JIT 编译器难以实现。

Patch 3 引入 CONFIG_BPF_JIT_KASAN Kconfig 选项，依赖于架构侧声明的 HAVE_EBPF_JIT_KASAN，当 BPF_JIT 和 KASAN_GENERIC 同时开启时自动生效。

Patch 4 是实现的核心：在 x86 JIT 编译器中新增 emit_kasan_check() 函数。该函数在每条被监控的内存访问指令前生成一段插桩代码，具体步骤为：（1）保存 9 个 caller-saved 和临时寄存器（rax, rcx, rdx, rsi, rdi, r8-r11）到栈上，共 72 字节，再额外减 8 字节对齐到 16 字节边界；（2）将访问地址加上偏移后存入 %rdi（第一参数寄存器）；（3）根据指令的读写类型（BPF_STX 为写、BPF_LDX 为读）和访问大小（BPF_B/H/W/DW 对应 1/2/4/8 字节）选择对应的 __asan_{load,store}N 函数并 call；（4）恢复所有寄存器。作者在 commit message 中明确说明，一条简单的 mov 0x0(%si),rbx 指令经插桩后会扩展为包含 9 次 push、栈对齐、mov、call、栈恢复、9 次 pop 共约 20+ 条指令的序列，"at the cost of a non negligeable increase in JITed code size"。

Patch 5 在 do_jit() 主循环中对 BPF_STX|BPF_MEM 和 BPF_LDX 类指令调用 emit_kasan_check()，同时排除 BPF_PROBE_MEM 和 BPF_PROBE_ATOMIC 指令（因为这类指令访问的地址可能故障，其自带的容错机制与 KASAN 检查冲突）。Patch 7 在 x86 Kconfig 中 select HAVE_EBPF_JIT_KASAN 以激活该功能。

测试方面（Patch 6 和 8），系列在 bpf_testmod.c 中添加专用 kfunc：对于读操作，通过 bpf_kfunc_kasan_uaf_*() 返回已 kfree 的指针制造 use-after-free，通过 bpf_kfunc_kasan_oob_*() 返回越界指针制造 global-out-of-bounds；对于写操作，通过 bpf_kfunc_kasan_poison() 直接调用 kasan_poison() 毒化 BPF map 内存。测试框架通过 klogctl() 读取内核日志验证是否出现预期的 KASAN 报告。

收益

作者未提供性能数据，这是一个以调试和安全为目标的功能。从代码逻辑推断：

• 为 BPF JIT 程序提供了与内核编译期代码同等的 KASAN 内存安全检测能力，可在运行时捕获 use-after-free 和 out-of-bounds 错误并生成标准 KASAN 报告
• 自测结果显示 16 个测试用例（覆盖 UAF/OOB x 读/写 x 1/2/4/8 字节）全部通过
• 该功能为调试工具，仅在同时启用 KASAN_GENERIC 和 BPF_JIT 时生效，不影响生产环境性能
• 当前为 RFC 状态，依赖 Xu Kuohai 的 verifier-JIT 数据传递工作尚未合并，atomic 操作的插桩尚未实现，作者计划在 LSFMMBPF 会议上进一步讨论

2. process_mrelease 加速回收与自动杀进程支持

系列：[RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support作者： Minchan Kim (Google)版本： RFC v1（3个patch）

背景

process_mrelease() 系统调用是 Linux 5.14 引入的用于加速 OOM 或容器关闭场景下进程内存释放的接口。其工作原理是在目标进程已收到 SIGKILL 后，由外部"回收者"（reaper）调用该系统调用来主动释放目标进程的地址空间。然而，当前实现存在两个显著的局限性：第一，process_mrelease() 在解映射（unmap）页面时只释放匿名页面（anonymous pages）的 swap cache，但对于干净的文件页（clean file folios）仅仅取消映射，将其留在 LRU 列表中等待标准内存回收机制最终释放，这延迟了系统内存的即时恢复；第二，用户空间必须先单独发送 SIGKILL 信号再调用 process_mrelease()，这两步操作之间存在调度竞争窗口——目标进程可能在 reaper 调用 process_mrelease() 之前就已经进入标准退出路径，从而绕过了加速回收的优化。

解决的问题

• 干净文件页在 process_mrelease() 后仍残留在 LRU 列表中，系统内存无法立即回收
• folio_mark_accessed() 进行的 LRU 移动操作在 unmap 路径中占用了约 55% 的开销，对即将释放的独占文件页而言完全无意义
• SIGKILL 与 process_mrelease() 的两步操作之间存在竞争条件，可能导致加速回收优化被跳过

如何做

整个方案围绕 MMF_UNSTABLE 标志展开，通过三个层次的优化来最大化内存回收效率。

Patch 1 的核心思路是将干净文件页的驱逐（eviction）直接集成到 TLB 批处理基础设施（mmu_gather）中。具体实现上，将原有的 free_pages_and_swap_cache() 重命名为 free_pages_and_caches()，新增 free_unmapped_file 参数。在 __tlb_batch_free_encoded_pages() 中，通过 mm_flags_test(MMF_UNSTABLE, mm) 检测当前是否处于 process_mrelease 路径。当该标志为真时，对于文件页调用新增的 free_file_cache() 函数，该函数尝试 folio_trylock() 获取 folio 锁，成功后调用 mapping_evict_folio() 将干净文件页直接从 page cache 中驱逐，然后 folio_unlock()。对于匿名页则继续走原有的 free_swap_cache() 路径。这种设计避免了引入额外数据结构，复用了现有的 TLB flush 批处理循环，在单一统一的循环中同时处理匿名页和文件页的释放。

Patch 2 针对 perf profiling 发现的热点进行优化。作者提供的性能分析数据显示，在 unmap_page_range 路径中，folio_mark_accessed() 占用了 55.75% 的时间，其中 __folio_batch_add_and_move 占 48.79%，workingset_activation 占 4.23%。对于 process_mrelease 场景下即将被释放的独占文件页，将其在 LRU 中移动完全是浪费。因此，在 zap_present_folio_ptes() 中增加判断：当 mm_flags_test(MMF_UNSTABLE, mm) 为真且 folio_mapcount(folio) < 2（即该 folio 为独占映射）时，跳过 folio_mark_accessed() 调用。

Patch 3 引入 PROCESS_MRELEASE_REAP_KILL UAPI 标志，解决两步操作的竞争问题。当用户空间传入该标志时，process_mrelease() 内部直接通过 do_send_sig_info() 向目标进程注入 SIGKILL，并使用专门的信号代码 KILL_MRELEASE（属于新增的 SIGKILL si_codes 节）。关键创新在于：在 kernel/signal.c 的 __send_signal_locked() 中，当检测到 sig == SIGKILL 且 info->si_code == KILL_MRELEASE 时，立即对目标进程的 mm 设置 MMF_UNSTABLE 标志。这确保了无论目标进程还是 reaper 谁先被调度执行，MMF_UNSTABLE 标志都已就位，从而保证加速回收优化始终生效。该操作需要 CAP_KILL 权限。

收益

作者提供了 perf profiling 数据（测试程序为 mmap_exit_test）：

• Patch 2 消除了 unmap 路径中约 55% 的 LRU 移动开销（针对独占文件页）
• Patch 1 将干净文件页的回收从异步 LRU 回收变为 unmap 路径中的同步即时驱逐，显著缩短内存释放延迟
• Patch 3 消除了 SIGKILL 与 process_mrelease 之间的竞争窗口，提供原子化的"杀死+回收"语义，适用于容器快速关闭和 OOM 处理场景

3. 移除不支持 large folio 的文件系统的只读 THP 支持

系列：[PATCH 7.2 v2 00/12] Remove read-only THP support for FSes without large folio support作者： Zi Yan (NVIDIA)版本： v2（12个patch）

背景

CONFIG_READ_ONLY_THP_FOR_FS 是一个标记为"EXPERIMENTAL"的 Kconfig 选项，其初衷是允许 khugepaged 和 MADV_COLLAPSE 在不支持 large folio 的文件系统上创建只读的 PMD 大小透明大页（THP）。然而，这一机制引入了大量复杂的维护负担。由于底层文件系统并不真正理解 large folio，内核不得不在文件描述符变为可写时（do_dentry_open()）通过 mapping->nr_thps 和 inode->i_writecount 配合内存屏障（smp_mb()）来检测并截断所有已创建的只读 THP，防止文件系统看到它不理解的大页。这导致了一系列问题：struct address_space 中需要维护 nr_thps 原子计数器；collapse_file() 和 do_dentry_open() 之间需要复杂的内存屏障配对来保证正确性；folio_check_splittable() 需要特殊处理不支持 large folio 的文件系统上的大页拆分；truncate_inode_partial_folio() 需要使用 try_folio_split_to_order() 而非直接的 folio_split()。

随着越来越多的主流文件系统（如 XFS、ext4、btrfs）已经原生支持 large folio，继续为不支持 large folio 的文件系统维护这套复杂的兼容机制已经不再值得。

解决的问题

• CONFIG_READ_ONLY_THP_FOR_FS 带来的维护复杂度：nr_thps 计数器、内存屏障配对、特殊拆分逻辑等散布在 VFS、mm、文件系统多个子系统中
• 只读 THP 在三种创建路径（page fault / MADV_COLLAPSE / khugepaged）中的行为不一致且依赖配置组合
• struct address_space 中的 nr_thps 字段及相关 filemap_nr_thps*() 函数对不支持 large folio 的文件系统来说是不必要的开销
• folio_check_splittable() 中针对 READ_ONLY_THP_FOR_FS 的特殊拆分限制使代码逻辑复杂化

如何做

系列采用"先使能新机制，再移除旧配置"的策略，共 12 个 patch 分为三个阶段。

阶段一（Patch 1-3）：在不依赖 READ_ONLY_THP_FOR_FS 的前提下，为支持 large folio（且支持的 order 包含 PMD_ORDER）的文件系统启用只读 THP 功能。Patch 1 修改 collapse_file() 和 collapse_scan_file()，将原有断言替换为资格检查。Patch 2 是正确性保障的关键：在 collapse_file() 中，在所有候选 folio 被锁定、解除映射且 TLB 被刷新之后，增加一个 folio 脏页检查循环。对于非 shmem 文件，如果发现任何 folio 为 dirty，则回滚整个 collapse 操作。其正确性保证在于此时所有 folio 已锁定且已解除映射并刷新 TLB，"No one else is able to write to these folios, since 1. writes via FS ops require folio locks; 2. writes via mmap require taking a fault and locking folio locks"。Patch 3 修改 file_thp_enabled() 的检查逻辑。

阶段二（Patch 4）：移除 CONFIG_READ_ONLY_THP_FOR_FS Kconfig 选项本身。

阶段三（Patch 5-12）：系统性清理所有残留代码。包括移除 filemap_nr_thps_inc/dec/read 函数、从 struct address_space 中移除 nr_thps 字段、大幅简化 folio_check_splittable()、简化 truncate_inode_partial_folio() 中的拆分逻辑等。

整体统计：删除 178 行，新增 49 行，净减少 129 行代码，涉及 13 个文件。

收益

作者未提供性能数据，这是一个代码简化和架构清理类的改动。从代码逻辑推断的预期收益：

• 净减少约 129 行代码，移除散布在 VFS、mm 和文件系统多个子系统中的复杂兼容逻辑
• 从 struct address_space 中移除 nr_thps 原子计数器，减小该高频使用的数据结构体积
• 消除 collapse_file() 与 do_dentry_open() 之间的内存屏障配对需求，降低并发正确性验证难度
• 只读 THP 的创建路径统一为：文件系统支持 PMD_ORDER large folio 即可使用所有三种创建方式，语义清晰一致

4. DAMON kdamond 异常终止后线程状态参数未重置

系列：[PATCH v2 0/2] mm/damon: reset thread status parameters upon kdamond termination作者： Liew Rui Yan（个人开发者）版本： v2（2个patch）

背景

DAMON（Data Access MONitor）是 Linux 内核中用于数据访问监控的子系统，其核心工作由内核线程 kdamond 执行。DAMON 提供了两个内建模块：DAMON_LRU_SORT（基于访问热度对 LRU 链表排序）和 DAMON_RECLAIM（基于冷数据回收内存）。这两个模块通过 sysfs 接口暴露 enabled 和 kdamond_pid 参数，供用户控制启停。

当用户向 enabled 写入 'N' 时，系统调用 damon_stop() 终止 kdamond 线程并重置 kdamond_pid = -1。然而，kdamond 也可能在没有用户请求的情况下"意外终止"（unexpected termination）。这种情况发生在 damon_commit_ctx() 调用失败时——该函数在入口处设置 maybe_corrupted = true，仅在成功完成后才将其置为 false。当 maybe_corrupted 保持为 true 时，kdamond 最终会自行退出。

解决的问题

• kdamond 异常退出后 enabled 仍为 'Y'，kdamond_pid 仍为过期值，用户无法通过 sysfs 重新启动 DAMON
• DAMON_LRU_SORT 和 DAMON_RECLAIM 编译进内核（built-in）时无法卸载重加载，一旦陷入该状态，"the only way to restore DAMON functionality is a full system reboot"

如何做

Patch 1 修复 mm/damon/lru_sort.c，Patch 2 以相同逻辑修复 mm/damon/reclaim.c，两者改动完全对称：

路径一：damon_{lru_sort,reclaim}_apply_parameters() 中 damon_commit_ctx() 失败时重置参数。 在 damon_commit_ctx(ctx, param_ctx) 调用之后增加错误检查：若返回错误，立即将 enabled 设为 false、kdamond_pid 设为 -1。

路径二：damon_{lru_sort,reclaim}_turn(false) 中增加回退逻辑。 原始代码在 damon_stop() 成功时才重置 kdamond_pid。补丁改为：当 damon_stop() 失败时，额外调用 damon_is_running(ctx) 检查 kdamond 是否实际仍在运行——若已不在运行，则将错误码清零并继续重置 kdamond_pid = -1。

收益

该修复消除了 DAMON 子系统中一个严重的可用性缺陷。在修复前，任何导致 damon_commit_ctx() 失败的场景都可能让 DAMON 陷入不可恢复状态，对于将 DAMON_LRU_SORT 或 DAMON_RECLAIM 编译进内核的生产系统而言，必须重启整机才能恢复内存管理功能。

5. blk-cgroup writeback 释放路径中的 use-after-free

系列：[PATCH] mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()作者： Breno Leitao (Meta)版本： v1（1个patch）

背景

Linux 内核的 cgroup writeback（cgwb）机制将每个 bdi_writeback 结构关联到一个 blkcg（块 I/O cgroup）的 CSS（cgroup subsystem state）引用。当 writeback 结构释放时，cgwb_release_workfn() 负责清理这些引用。commit 59b57717fff8 ("blkcg: delay blkg destruction until after writeback has finished") 引入了 blkcg_unpin_online() 调用以延迟 blkg 销毁，但将其放在了 css_put() 之后。

解决的问题

• cgwb_release_workfn() 中存在 use-after-free：css_put(wb->blkcg_css) 可能释放 CSS 的最后一个引用，触发异步释放链 css_free_rwork_fn -> blkcg_css_free -> kfree。随后 blkcg_unpin_online(wb->blkcg_css) 解引用该指针访问 blkcg->online_pin 时，底层内存可能已被释放。KASAN 报告：

  BUG: KASAN: slab-use-after-free in blkcg_unpin_online
  Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531
  

• 作者指出 "I am seeing this crash sporadically in Meta fleet across multiple kernel versions"，该问题在 Meta 生产集群中跨多个内核版本偶发触发。

如何做

修复方案：在 mm/backing-dev.c 的 cgwb_release_workfn() 中，将 blkcg_unpin_online(wb->blkcg_css) 调用移到 css_put(wb->blkcg_css) 之前。这样在 blkcg_unpin_online() 访问 blkcg->online_pin 时，CSS 引用计数尚未被释放，blkcg 结构体保证仍然存活。

Fixes: 59b57717fff8 ("blkcg: delay blkg destruction until after writeback has finished")

收益

该修复解决了一个影响生产环境的内存安全漏洞。在高负载、频繁创建销毁 cgroup 的场景下更易触发。此修复已标记 Cc: stable，将被回移到所有受影响的稳定版内核。

6. vmalloc shrinker 路径缺少 vmap_purge_lock 导致并发竞态

系列：[PATCH] mm/vmalloc: Take vmap_purge_lock in shrinker作者： Uladzislau Rezki (Sony)版本： v1（1个patch）

背景

Linux 内核的 vmalloc 子系统维护了一个 per-node 的 vmap area 池。commit 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools") 引入了一个 shrinker 回调，允许内存回收路径缩减这些池。shrinker 的 scan 回调 vmap_node_shrink_scan() 会调用 decay_va_pool_node() 来释放池中缓存的 vmap area。与此同时，__purge_vmap_area_lazy() 是另一个会调用 decay_va_pool_node() 的路径，它通过 lockdep_assert_held(&vmap_purge_lock) 断言必须持有该锁。

解决的问题

• shrinker 路径调用 decay_va_pool_node() 时未持有 vmap_purge_lock。作者指出 "decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks"

如何做

修复仅增加一行代码：在 vmap_node_shrink_scan() 函数的 for_each_vmap_node 循环前，使用 guard(mutex)(&vmap_purge_lock) 获取互斥锁。guard(mutex) 是内核的 RAII 风格锁守卫宏，在函数返回时自动释放锁。

staticunsignedlong
vmap_node_shrink_scan(struct shrinker *shrink, struct shrink_control *sc)
{
structvmap_node *vn;

+ guard(mutex)(&vmap_purge_lock);
 for_each_vmap_node(vn)
  decay_va_pool_node(vn, true);

return SHRINK_STOP;
}

Fixes: 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools")

收益

该修复消除了 vmalloc 子系统中一个潜在的并发安全问题。在内存压力较高、shrinker 频繁被调用的场景中，并发的 decay_va_pool_node() 可能导致 vmap area 链表损坏，造成虚拟地址空间泄漏甚至内核 panic。此修复标记 Cc: stable。

7. Dynamic Housekeeping Management (DHM) via CPUSets

系列：[PATCH v2 00/12] Dynamic Housekeeping Management (DHM) via CPUSets作者： Qiliang Yuan（个人开发者）版本： v2（12个patch）

背景

Linux 内核的 housekeeping（管家）机制负责将内核噪声源（如 RCU 回调、定时器中断、workqueue、调度器负载均衡等）限制在特定 CPU 上运行，从而让其余 CPU 可以专注于延迟敏感的用户态工作负载。然而，这套机制长期以来完全依赖启动参数（isolcpus=、nohz_full=、rcu_nocbs=）进行静态配置。一旦系统启动完成，housekeeping 掩码就固定不变，任何调整都需要重启节点。在 Kubernetes 等容器编排环境中，工作负载的隔离需求是动态变化的，静态配置意味着高昂的运维成本和资源浪费。

解决的问题

• 内核 housekeeping 掩码在启动后不可变更，运行时无法扩展或收缩隔离 CPU 集合
• 缺乏统一的机制同时通知所有受 housekeeping 掩码影响的子系统进行同步更新
• RCU NOCB 模式在未配置启动参数时无法在运行时激活
• 在 SMT（超线程）平台上，不当的隔离边界划分可能将同一物理核心的两个硬件线程分到不同域

如何做

整个方案分为四个逻辑阶段：基础设施层、子系统适配层、CPUSet 集成层和安全防护层。

基础设施层：在 kernel/sched/isolation.c 中引入 blocking notifier chain（housekeeping_notifier_list），定义 struct housekeeping_update 数据结构，通过 housekeeping_register_notifier() / housekeeping_update_notify() 接口让各子系统注册回调。核心函数 housekeeping_update_all_types() 在 housekeeping_mutex 保护下，对每个启用的 hk_type 通过 rcu_assign_pointer() 进行 RCU-safe 的指针替换，随后 synchronize_rcu() 确保旧掩码不再被引用后释放。

子系统适配层（patch 3-8）：各子系统实现各自的 notifier_block 回调，包括：

• RCU：新增 rcu_init_nocb_dynamic() 支持运行时 NOCB kthread 重组织，通过 CPU hotplug 序列安全执行状态转换
• Tick/NOHZ：重构 tick_nohz_full_setup() 使其可运行时调用，预先激活所有 possible CPU 的 context tracking
• genirq：遍历所有活跃 IRQ 重新应用 affinity
• Scheduler：收到变更通知后 rebuild_sched_domains()
• Workqueue + MM compaction：更新 unbound workqueue CPU 掩码和 kcompactd 线程 affinity

CPUSet 集成层：在 root cgroup 注册 cpuset.housekeeping.cpus 控制文件，仅允许 root cgroup 写入，调用 housekeeping_update_all_types() 一次性更新所有类型并广播通知。

安全防护层：新增 cpuset.housekeeping.smt_aware 布尔控制文件，启用后验证新掩码中每个 CPU 的 SMT sibling 是否都包含在掩码内，防止拆分超线程对。

收益

作者未提供性能 benchmark 数据。从代码逻辑推断的预期收益：消除因隔离边界调整而需要的节点重启，在 Kubernetes 等编排环境中实现秒级别的在线隔离重配置；通过 cgroup v2 标准接口暴露控制面，天然与 systemd、containerd 等工具链集成；SMT-aware 防护可避免错误配置导致的性能退化。该方案覆盖了 RCU、Tick、IRQ、Scheduler、Workqueue、Watchdog、kcompactd 共 8 个子系统的动态重配置。

8. liveupdate: 修复模块卸载与反注册 API

系列：[PATCH v4 00/11] liveupdate: Fix module unloading and unregister API作者： Pasha Tatashin (Soleen)版本： v4（11个patch）

背景

Live Update Orchestrator（LUO）是 Linux 内核的热更新框架，允许内核在不中断运行中虚拟机的情况下进行升级。LUO 的核心概念包括 file handler（负责特定类型文件描述符的保存和恢复）和 FLB（File-Level Blob，存储跨内核更新的持久化状态）。在 v4 之前的实现中，模块在注册时会立即通过 try_module_get() 递增引用计数，导致模块在整个注册期间被"钉住"，即使没有任何 live update session 在进行中也无法卸载。此外，强制卸载模块时反注册返回的错误码会被忽略，在全局列表中留下悬空指针。

解决的问题

• 模块注册 file handler/FLB 后被无限期钉住，即使没有活跃 session 也无法正常 rmmod
• 强制模块卸载时反注册返回错误被忽略，导致 LUO 全局列表中出现 dangling pointers
• luo_flb_get_private() 中存在数据竞争：多线程并发调用时 initialized 标志可能被多次执行
• 反序列化的 KHO 数据可能未以 null 结尾，使用 %s 打印可能越界读取内核内存

如何做

核心设计思想是将模块引用计数的粒度从"注册即钉住"收窄为"使用时才钉住"，并引入全局读写信号量（luo_register_rwlock）替代原有的 session quiesce 机制。

并发保护：引入静态 spinlock 配合 smp_load_acquire() / smp_store_release() 实现线程安全的 lazy initialization。全局 rwsem 在遍历路径上加读锁，在注册/反注册路径上加写锁。

引用计数收窄：移除注册时的 try_module_get()，改为在 luo_flb_file_preserve_one() 和 luo_flb_retrieve_one() 等实际使用路径中动态获取引用，在对应的 finish/unpreserve 路径中释放。

API 简化：将 liveupdate_unregister_file_handler() 和 liveupdate_unregister_flb() 的返回类型从 int 改为 void，遵循"模块卸载时的反注册不应失败"的设计原则。引入 luo_flb_unregister_all() 辅助函数自动清理关联 FLB。

安全加固：对不可信字符串将 %s 替换为 %.*s 防止越界读取。

收益

作者未提供性能数据。预期收益：模块在没有活跃 session 时可正常卸载；消除了 dangling pointers 风险；净减少约 67 行代码（151 insertions, 218 deletions），void 返回类型的 API 与内核其他子系统反注册惯例一致。

9. folio_unmap_invalidate() 中的 use-after-free 修复

系列：[PATCH] mm: Call ->free_folio() directly in folio_unmap_invalidate()作者： Matthew Wilcox (Oracle)版本： v1（1个patch）

背景

folio_unmap_invalidate() 是在 commit 4a9e23159fd3 中引入的辅助函数，用于在 truncate 路径中将 folio 从 page cache 中移除并释放。该函数在完成移除操作后会调用 filemap_free_folio() 来执行文件系统特定的 free_folio 回调。然而，在 folio 已从 mapping 的 i_pages xarray 中移除之后，mapping 本身不再被该 folio "钉住"，mapping 所属的 inode 可能随时被释放。此时再通过 mapping->a_ops->free_folio 访问操作表就会触发 use-after-free。

这个漏洞由 Google Big Sleep 团队（利用大型语言模型辅助发现安全漏洞的项目）报告。

解决的问题

• folio 从 i_pages xarray 移除并释放 inode 锁后，mapping->a_ops 可能成为悬空指针，触发 use-after-free

如何做

修复方案遵循了 __remove_mapping() 中已有的安全模式：在释放 mapping 的锁之前，先将 free_folio 函数指针保存到局部变量中。

1. 声明局部函数指针 void (*free_folio)(struct folio *)
2. 在 spin_unlock(&mapping->host->i_lock) 之前读取并保存 mapping->a_ops->free_folio
3. 释放锁后通过局部指针调用 free_folio(folio)
4. 将 filemap_free_folio() 改为 static 函数（它在 filemap.c 之外已无调用者）

Fixes: 4a9e23159fd3 ("mm/truncate: add folio_unmap_invalidate() helper")

收益

该修复消除了一个可被利用的 use-after-free 安全漏洞。带 Cc: stable 标签，需回溯移植到所有受影响的稳定版内核。将 filemap_free_folio() 限定为 static 减少了导出符号，符合最小暴露原则。

10. 按 NUMA 节点拆分文件 i_mmap 反向映射树

系列：[PATCH 0/3] mm: split the file's i_mmap tree for NUMA作者： Huang Shijie (Hygon，海光)版本： v1（3个patch）

背景

在 NUMA 架构的大型服务器上，文件的反向映射树（i_mmap interval tree）是记录所有映射该文件的 VMA 的核心数据结构。每个 address_space 中只有一棵 i_mmap 红黑树，所有对该文件的 mmap 映射都受同一把 i_mmap_rwsem 保护。在大规模 NUMA 系统上（如 Hygon 服务器拥有 12 个 NUMA 节点、384 个 CPU），当大量进程并发执行 execve 时，共享库文件（libc.so、ld.so）的 i_mmap 树可能包含超过 6000 个 VMA，锁竞争成为严重瓶颈。

解决的问题

• 单一 i_mmap 树的锁竞争问题：所有 CPU 争夺同一把 i_mmap_rwsem 锁
• NUMA 本地性差：所有节点的 VMA 混杂在同一棵树中，跨节点访问树节点导致远端内存访问延迟

如何做

Patch 1：使用 mapping_mapped() 简化直接检查 RB_EMPTY_ROOT 的代码，为后续修改做准备。

Patch 2：引入 get_i_mmap_root() 访问器，将所有直接访问 &mapping->i_mmap 的 18 个文件统一改为通过该访问器间接获取，建立抽象层。

Patch 3（核心）：在 CONFIG_NUMA 下将 address_space 中的单棵 i_mmap 树替换为 struct rb_root_cached **i_mmap 指针数组，每个 NUMA 节点对应一棵独立的 interval tree，通过 kzalloc_node() 分配在对应节点上。vm_area_struct 新增 tree_idx 字段记录归属节点。vma_interval_tree_foreach() 宏重写为依次遍历所有 sibling trees。新增 vma_count 字段维护映射计数，mapping_mapped() 改为直接读取该计数。非 NUMA 配置下所有抽象层退化为直接访问，零开销。

收益

作者在 Hygon 12 NUMA 节点、384 CPU 服务器上使用 UnixBench execl 测试：

• 77% 性能提升（10次平均）
• 测试命令：./Run -c 384 execl

这一显著提升来源于将单一全局锁的竞争分散到多棵 NUMA 本地子树，VMA 数量从 6000+ 分散到约 500/节点，红黑树高度降低，同时消除了跨 NUMA 的远端内存访问。

11. SLUB 延迟 freelist 构建优化批量分配

系列：[PATCH v6] mm/slub: defer freelist construction until after bulk allocation from a new slab作者： Shengming Hu (ZTE，中兴通讯)版本： v6（1个patch）

背景

SLUB 分配器在分配一个新的 slab 页面时，会立即构建完整的 freelist——遍历所有 object slot 进行初始化并链接成单链表。启用 CONFIG_SLAB_FREELIST_RANDOM=y 时还需随机化洗牌。在批量分配场景中，刚分配的新 slab 的所有对象可能立即被全部消耗，此时预先构建的 freelist 完全是浪费——"the freelist built during slab allocation is discarded immediately as a result"。

解决的问题

• 新 slab 分配时的冗余 freelist 构建开销：先构建再拆除是双重浪费
• CONFIG_SLAB_FREELIST_RANDOM=y 下 shuffle_freelist() 的额外随机化开销在整个 slab 都被消耗时完全无用

如何做

核心思想是将 freelist 构建从 slab 分配时推迟到分配对象之后，仅为未被分配出去的"剩余"对象构建 freelist。

引入 slab_obj_iter 迭代器抽象：统一封装 RANDOM/非 RANDOM 模式下遍历 free object 的逻辑。init_slab_obj_iter() 初始化迭代器（RANDOM 模式下选取随机起始位置），next_slab_obj() 返回下一个 free object。

移除 allocate_slab() 中的 freelist 构建：不再调用 shuffle_freelist() 或手动构建循环。旧的 shuffle_freelist() 和 next_freelist_entry() 被完全删除。

消费侧按需构建：alloc_from_new_slab() 先通过迭代器取出所需数量的对象，然后 build_slab_freelist() 仅为剩余对象构建 freelist。如果整个 slab 被消耗完，freelist 为 NULL，完全跳过构建。

收益

作者提供了 slub_bulk_bench 微基准测试数据（QEMU x86_64, 8 SMP, 1GB RAM）：

CONFIG_SLAB_FREELIST_RANDOM=n：

CONFIG_SLAB_FREELIST_RANDOM=y：

每对象分配时间降低约 **32% 至 70%**。作者指出该 benchmark "is intended to isolate the cost removed by this change"，实际工作负载收益取决于命中新 slab 补充路径的频率。

12. 不可恢复内存故障时立即 panic 选项

系列：[PATCH v3 0/3] mm/memory-failure: add panic option for unrecoverable pages作者： Breno Leitao (Meta)版本： v3（3个patch）

背景

Linux 内核的 memory-failure 处理机制在检测到硬件内存错误时，会尝试恢复受影响的页面。然而，对于内核自身使用的页面（slab 对象、page table、kernel stack、vmalloc 分配等），memory-failure handler 目前缺乏恢复能力，只能将结果记录为 "Ignored" 并继续运行。

作者描述了一个生产环境真实案例：在一台 arm64 服务器上，multi-bit ECC 错误击中了 dentry cache slab page，memory_failure() 报告 "recovery action for get hwpoison page: Ignored"，系统继续运行。67 秒后，d_lookup() 访问了中毒的 cache line，触发 synchronous external abort 导致内核崩溃。"the system crashes later at an unrelated code path, making root cause analysis unnecessarily difficult"。

解决的问题

• 不可恢复内存错误后的延迟崩溃问题：受损数据留在内核中，必然导致静默数据损坏或随机延迟崩溃
• 崩溃现场丢失导致根因分析困难
• reserved page 分类不当：之前未区分属于内核的 reserved page

如何做

Patch 1：为 reserved page 正确分类为 MF_MSG_KERNEL。引入 sysctl sysctl_panic_on_unrecoverable_mf（默认 0）和 /proc/sys/vm/panic_on_unrecoverable_memory_failure 接口。核心判定函数 panic_on_unrecoverable_mf() 在恢复结果为 MF_IGNORED 且页面类型为 MF_MSG_KERNEL、MF_MSG_KERNEL_HIGH_ORDER 或 MF_MSG_UNKNOWN 时触发 panic。

Patch 2：添加 CONFIG_BOOTPARAM_MEMORY_FAILURE_PANIC 编译选项，开启后默认值为 1。

Patch 3：完整文档更新。

收益

• 获得干净的崩溃转储：在硬件错误发生的第一时间 panic，crash dump 直接包含原始错误上下文
• 消除静默数据损坏风险：不再允许内核继续使用已中毒的内存
• 灵活配置：默认值 0 保证向后兼容；Kconfig 适合大规模集群统一编译部署；sysctl 提供运行时控制

总结

新机制 / 新接口

性能优化

Bug Fix

内部优化 / 清理