2026 年 6 月 28 日,Linus Torvalds 正式发布了 Linux 7.2-rc1 并宣布关闭 7.2 的合并窗口(Merge Window)。在这短短两周时间里,共有 13,412 个非合并提交(non-merge commits) 涌入主线内核,由创纪录的 2,138 位贡献者 共同完成。
这使得 7.2 成为自 2024 年 6.7 开发周期(15,418 个 commits)以来最繁忙的一个合并窗口。尽管合并窗口后半期的提交依然遵循惯例侧重于稳定性修复,但其中包含的架构级重构、核心安全清算以及虚拟化演进,依然为现代 Linux 栈带来了极为深远的影响。
本文将对 Linux 7.2 合并窗口中的核心技术变更进行全面盘点与深入拆解。
一、 核心内核与内存管理:更轻量、更智能的内存栈
在内存管理(MM)与 Swap 子系统方向,内核团队延续了对静态元数据开销的"瘦身"计划,并进一步提升了内存性能。
1. Swap 基础设施统一与元数据清零
随着 Folio 架构的全面铺开,7.2 深入清理了 Swap 子系统的历史遗留问题。本次合并的一系列补丁成功统一了匿名页(Anonymous Folios)与共享内存页(Shared-memory Folios,如 shmem/tmpfs)在底层 Swap 路径中的处理逻辑。
-
架构收益:以往 Swap 结构体为每个 Page 分配的静态元数据开销被大幅削减(静态开销已接近于零)。
-
性能表现:减少了换页和内存高压场景下的 TLB 缺失,真实工作负载的整体吞吐量和响应时延均获得轻微提升。
2. khugepaged 自动化支持 mTHP
多尺寸透明大页(mTHP,如 16KB、64KB、512KB 等)此前已引入内核,但在自动化合并层面仍有不足。在 7.2 中,后台守护线程 khugepaged 获得了自动创建 mTHP 的能力。
- 技术背景 :传统 2MB 大页在面对零碎内存时容易引发分配延迟与严重的内存浪费。mTHP 提供了折中的分配粒度,而
khugepaged的自动支持意味着系统可以在后台默默整理碎片,无需应用显式配置即可提升 TLB 命中率。
3. Page Cache 冗余 THP 选项彻底剥离
内核移除了针对只读文件在 Page Cache 中强行分配透明大页的过渡性配置(CONFIG_READ_ONLY_THP_FOR_FS)。该选项原本是为原生不支持 Large Folio 的文件系统提供的变通方案。随着主流文件系统的 Folio 化完成,这一变通层被彻底清理。注:个别尚未支持原生 Large Folio 的老旧文件系统在升级到 7.2 后,只读性能可能会出现短期回调。
二、 文件系统与块 I/O:协议升级与旧重塑
文件系统子系统在传输吞吐、安全加固及废弃代码清理方面均有动作:
-
NFS 默认传输块大提升至 4MB :针对物理内存 \\ge 16\\text{GB} 的系统,NFS 客户端与服务端的默认传输块大小(
rsize/wsize)从传统的 1MB/512KB 提升至 4MB。在大带宽网卡(100GbE+)与高性能 NVMe 环境下,这大幅降低了 RPC 包头开销与中断频率。 -
SMB(ksmbd)支持压缩传输与存储:内核级 SMB 服务端新增了对 NTFS/SMB 压缩格式文件的读写支持,并实现了网络传输数据流的实时压缩/解压缩,进一步消除了 Linux 在企业级文件共享场景中与 Windows Server 的功能代差。
-
NTFS3 驱动加固:Paragon 贡献的 NTFS3 驱动迎来了大规模维护与磁盘元数据健壮性加固,防范损坏镜像导致的内核崩溃,并补齐了 Windows 原生符号链接(Symbolic Links)的解析能力。
-
EROFS 废弃
fscache后端清理 :彻底清除了 5.19 时代引入、已被弃用两年的 EROFSfscache旧后端,转向现代化的容器只读镜像挂载基础设施。 -
Ceph 客户端手动重置:Ceph 新增了管理员手动重置客户端的机制,以解决网络异常或节点宕机时客户端持有锁无法释放导致的集群阻塞问题。
三、 安全相关:彻底告别 strncpy() 与 LSM 的拉锯
7.2 在安全领域的最大里程碑,莫过于一项持续多年的"清道夫"工程终于圆满收官。
彻底淘汰 strncpy():
历时 6 年 | 70 位开发者 | 362 个 Commit -> 代码库彻底清零 (0 遗留)
替代方案: strscpy() / strscpy_pad() / sizeof_field()
1. strncpy() 在内核中彻底清零
经过 6 年的持续清理、70 位贡献者的 362 个提交,strncpy() 实现已从 Linux 内核源码树中被完全移除 。由于 strncpy() 极其容易导致非 NULL 终止字符串及缓冲区溢出风险,内核现在全面强制改用 strscpy()、strscpy_pad() 等具备严格边界防护和错误返回机制的替代函数。
2. IMA(完整性测量架构)内存外置
IMA 获得了将测量日志(Measurement Logs)暂存导出至内核外部的能力。以往大型服务器在长时间运行后,IMA 记录的每个执行文件 Hash 会消耗数 GB 不可 Swap 的内核驻留内存;导出暂存机制在保持安全链不中断的前提下,显著释放了内核内存占用。
3. Landlock 扩展与 Hornet LSM 被拒
-
Landlock 网络控制 :非特权沙箱机制 Landlock 新增了对 UDP Socket 的
bind与connect细粒度控制,同时支持抑制特定的拒绝日志输出,防止攻击者利用试错触发日志暴击(Log Flooding)。 -
Hornet LSM 再次被拒:旨在为 BPF 程序加载提供额外安全审查的 Hornet LSM 再次引发争议。尽管开发者对其进行了大幅重构,但 BPF 维护者与 Linus 仍认为其架构过度入侵且打破了已有的验证器(Verifier)设计。Linus 在合并窗口前明确拒绝了该 Pull Request。
四、 虚拟化与硬件支持:硬件级执行控制与底层扩展
1. KVM 硬件级执行控制(MBEC / GMET)
KVM 在 7.2 中完美支持了 Intel MBEC (Mode-Based Execution Control)与 AMD GMET(Guest-Mode Execution Trap)。
- 原理与优势:此前虚拟机在内核态与用户态间切换代码执行权限时,经常需要触发缺页异常并陷回(Trap)到宿主机的 KVM 中进行检查。MBEC/GMET 允许硬件直接区分 Guest 的 User mode 与 Kernel mode 执行权限,使嵌套虚拟化(如 Windows VBS / HVCI 虚拟化安全层)在 Linux KVM 上的运行损耗降低了 30% 以上。
2. 硬件与驱动扩展
7.2 合并了大量最新的 SoC、网络及外设驱动:
-
RISC-V 生态:新增 UltraRISC DP1000 SoC Pin 控制器与 PCIe Host 控制器、勘智 K230 时钟驱动。
-
高通 Snapdragon X 生态 :大规模补全了针对 X1P42100(Snapdragon X Elite 系列)、IPQ9650 等 SoC 的视频/相机时钟、PMIC 及 Interconnect 驱动。
-
外设支持:新增 OneXPlayer(壹号掌机)手柄控制器、Rakk 游戏外设、Wacom W9000 触控屏,以及 Virtio CAN 虚拟化接口支持。
五、 工程生态与 LLM 浪潮:AI 补丁的喜与忧
除了代码本身的演化,7.2 窗口还展现了当下 Linux 社区正经历的开发范式转变。
┌─────────────────────────────────────────┐
│ Linux 7.2 开发者生态图景 │
└────────────────────┬────────────────────┘
│
┌──────────────────────┴──────────────────────┐
▼ ▼
┌─────────────────────────┐ ┌─────────────────────────┐
│ make sbom 机制 │ │ LLM 补丁冲击争议 │
│ 动态提取当前配置编译文件│ │ 2138 位贡献者 (历史新高)│
│ 精确输出二进制级 SBOM │ │ 706 个 Assisted-by 提交 │
└─────────────────────────┘ │ ARM64 维护者因审查过载 │
│ 暂停接收新特性 │
└─────────────────────────┘
1. 原生 make sbom 机制
为应对供应链安全规范,内核构建系统引入了 make sbom 指令。该工具利用源码中的 SPDX 标记,仅提取当前 .config 配置下实际参与编译的文件信息 。相比于传统的外部静态扫描工具,make sbom 生成的软件物料清单达到了二进制级别的精准度。
2. AI 补丁洪流带来的审查危机
本次合并窗口中,包含 Assisted-by: 标签的提交达到了 706 个(约占总量的 5%),展现了 LLM 工具在辅助内核开发上的快速普及。
然而,AI 的引入也带来了沉重的维护开销。ARM64 架构的 KVM 维护者在 Pull Request 中直言:7.2 版本中 ARM64 KVM 没有引入任何新特性,全部为修复补丁。原因在于邮件列表中充斥着海量由 LLM 自动生成、看似合理但隐藏深层缺陷的"假修复"补丁,极其消耗精力,导致维护者根本无暇审查和合并有效的新功能。
总结与展望
Linux 7.2-rc1 的发布,既展示了内核在内存管理、安全清理和硬件虚拟化方面的扎实演进,也揭示了 AI 浪潮下开源社区在代码审查和质量控制方面面临的新挑战。
按照标准的开发周期,7.2 正式版本(Release Candidate)经过大约 7-8 个 rc 版本的测试与稳定后,预计将于 2026 年 8 月 16 日 正式发布。对于追踪 upstream 主线的内核工程人员而言,Swap 基础设施变更、mTHP 的实际表现以及 KVM 硬件控制特性的落地,将是后续测试和性能调优中重点关注的方向。
