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 包头开销与中断频率。SMBksmbd支持压缩传输与存储内核级 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 / GMETKVM 在 7.2 中完美支持了 IntelMBECMode-Based Execution Control与 AMDGMETGuest-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 生态大规模补全了针对X1P42100Snapdragon 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 硬件控制特性的落地将是后续测试和性能调优中重点关注的方向。
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 包头开销与中断频率。SMBksmbd支持压缩传输与存储内核级 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 / GMETKVM 在 7.2 中完美支持了 IntelMBECMode-Based Execution Control与 AMDGMETGuest-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 生态大规模补全了针对X1P42100Snapdragon 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 硬件控制特性的落地将是后续测试和性能调优中重点关注的方向。
