Linux Kernel 7x系列主要发布记录
2026-03-24 15:04:54 
阿炯
上接《Linux Kernel 6z系列主要发布记录》。
Linux 内核将迎来 7.0 大版本
Linus Torvalds 在2026年2月上旬宣布下一代内核版本将命名为 Linux v7.0，并非传统意义上的 6.20。这标志着 Linux 内核版本号进入新的整数阶段。Linux 7.0 开发周期的合并窗口已经开启，并预计在 2026 年 4 月中旬与 Ubuntu 26.04 LTS 等主流发行版同步推出。他在邮件列表中提到由于自身对更高数字不太方便记忆，他选择将下一个主要内核版本命名为 7.0。Linux 的版本号通常在 x.19 之后跳到下一个整数，这一次也是遵循同样的传统。合并窗口将持续约两周，之后进入一系列 Release Candidate 阶段。
v7.0 不只是在版本号上跨越，也预计带来多项性能与硬件支持改进，包括但不限于：
新的硬件支持：如针对 AMD 新 GPU IP 和 Intel Xe3P 系列显卡的新驱动准备。
内核子系统性能优化，如 IO_uring IOPOLL 改进，用更高效的数据结构提升 I/O 性能表现。
多队列图形 / 加速器支持（如 Intel 多队列支持，有助于 AI 推理和高并发图形任务）。
更深度的 Rust 语言与 LTO（Link-Time Optimization）内核构建支持，助推现代内核开发灵活性与性能。
其推出将为服务器、桌面及嵌入式平台带来更广泛的硬件兼容性和调度优化，这对于追求最新平台支持和性能优化的开发者及企业用户来说，是一个重要的内核迭代节点。同时伴随 7.0 发布的还有大量社区贡献的驱动及子系统更新。
7.x的几个主要特点
1. 硬件兼容全面升级
深度适配Intel Nova Lake/Diamond Rapids、AMD Zen 6架构，首次支持高通骁龙X2等ARM平台，扩展多设备生态覆盖。
2. 系统性能多维优化
调度器引入TIP机制提升任务连续性，内存管理与I/O子系统增强，显著改善高负载场景响应速度与资源效率。
3. Rust语言正式"转正"
结束两年实验阶段，确立为内核长期支持语言，提升代码安全性与可维护性，获开发者社区广泛认可。
4. 文件系统与存储革新
exFAT顺序读取提速约10%，EXT4/F2FS并发能力增强，并新增SPI NAND等新型存储技术适配。
5. 用户体验显著提升
游戏/桌面流畅度优化，支持编译时自定义启动Logo，完善硬件监控与标准化错误报告机制。
Linux内核版本经历了从2.6到3.0、从4.20到5.0、从5.19到6.0，现在从6.19变成了7.0。在Linus Torvalds看来，版本号只是数字且没有其他含义（无技术上的里程碑意义、无API兼容问题）。最近是每发布20次，就有一个大版本号变化。Linux Kernel v7.0带来了以下惊喜。
1. Rust成为官方开发语言
从1991年Linux诞生以来，一直用C语言开发。C语言很强大，但是犯的错误也不可饶恕：它会让系统崩溃、内存数据损坏、制造安全漏洞。Rust可以从语法层面规避这些问题，由于它比较新，一些老师傅不愿意接受它。在2025年日本东京内核维护者峰会上，终于达成了共识：Rust在内核开发社区不再是实验性质，它是内核的一部分，不搬家了。历经五年，Rust终于转正。在这五年时间，C代码增长了34M行，Rust接近25K行，这说明Rust并没有取代C。
下面拉出不愿意接受Rust的老师傅名单：
* Christoph Hellwig, DMA子系统维护者，说Rust是毒瘤，并因此离职
* Wedson Almeida Filho, 来自微软的工程师，为Linux贡献Rust代码的核心人员，说Rust是非技术的胡说八道
* Alex Gaynor, Rust项目的联合负责人，在Rust官宣认可的同一周离职
* Ted Ts'o，备受尊敬的内核开发者之一，直言不讳地说不能强迫大家学Rust
Linus Torvalds力挺Rust，安卓第16版打包了Rust内核代码（ashmen分配器），在上百万台设备运行，证实Rust可以产品使用。
2. 后量子密码学（Post-Quantum Cryptography）
每次内核加载驱动程序或者其他软件模块，都要检查它的数字签名，确保没有被篡改，就像检查信封上的封蜡。问题是，未来的量子计算机计算能力很强，可能会伪造这些封印。Linux Kernel 7.0引入了ML-DSA签名，就算量子计算机也无可奈何。
ML-DSA（Module-Lattice-Based Digital Signature Algorithm）是一种基于模数格（module lattice）数学原理的数字签名算法。它是 FIPS 204(Federal Information Processing Standards，联邦信息处理标准)的一部分，获得了 NIST（National Institute of Standards and Technology，美国国家标准与技术研究院） 的批准。这个算法的特别之处在于，它利用了 格理论（lattice-based cryptography）中的数学问题，格理论被认为对传统计算机和量子计算机都具有很高的安全性，因此被认为是未来对抗量子攻击的潜在解决方案之一。
量子计算机还没出来，为啥Linux内核就开始考虑这种攻击呢？别有用心者一直在收集加密过的数据，一旦量子计算机出来，就可以大规模解密这些数据，所以需要未雨绸缪。
这种防范不是无中生有的，比如2011年NIST宣布不再使用SHA-1签名，2017年就出现了针对SHA-1签名的攻击。
3. XFS自我修复
日常用EXT4文件系统，而XFS主要用在数据中心和大存储系统里。断电、硬件瑕疵、软件臭虫等原因会导致文件系统损坏，修复过程需要让系统处于离线状态。新的改进可以让XFS在运行时自我修复，不需要人工干预，不会影响在线服务。
xfs_header实时监测文件系统健康状态，如果发现元数据损坏（计算校验和比对），从备份里拷贝一份恢复，用户程序不会受到影响。
在企业级存储里，XFS被大规模应用，对他们来说这次更新意味着实打实的资金节省。
4. io_uring：百万美金的修复赏金得到解决
每次读写文件、在网络上收发数据，都要通过系统调用访问Linux内核。为什么不直接调用内核呢？这是为了提高系统安全性和健壮性。内核代码在内核空间运行，用户代码在用户空间运行，二者具有不同的执行上下文（堆、栈、内存映射、指令指针等）。系统调用会把执行上下文从用户空间切换到内核空间，其中包括安全检查。
如果每次调用都做安全检查，会降低系统性能，影响I/O吞吐量，所以Linux提供了io_uring这个快速车道。io_uring是任何操作系统I/O操作最快的方式之一，但因为没有“安全摄像头”，容易被黑客盯上。比如2022年，谷歌60%的安全漏洞是io_uring引起的。谷歌悬赏百万美金修复这个问题，Chrome OS则是彻底关闭了io_uring。
核心问题是：io_uring绕过了传统的系统调用，导致标准安全过滤器seccomp无法碰到它。v7.0给io_uring加上了基于BPF（Berkeley Packet Filter，用过tcpdump的应该熟悉）的过滤器，系统管理员可以精确控制安全策略，不用彻底关闭它。现在可以既要安全又要性能了，虽然等待时间太长太长，终归是值得的。
5. 进程调度器：更少模式，更高性能
进程调度算法直接影响系统性能和用户体验，新的调度算法从四种抢占模式改成了两种，以适应现代体系架构：PREEMPT_LAZY 和 PREEMPT_FULL 。
PREEMPT_LAZY 这个选项很有意思。它恰到好处：对普通任务采取宽松的抢占策略（让他们完成工作），而对实时任务则采取积极的抢占策略。想象一下，一位经理会等员工说完话才打断他们，除非发生了火警。
与此同时，一个历时十年开发的时间片(time-slice)扩展补丁也已合并。桌面 Linux 用户应该会感受到系统更流畅，不过 7.0 版本的正式基准测试结果尚未公布。
6. 容器和文件系统的改进
容器在云端和开发人员中用得比较多，比如docker。通过容器可以建立服务之间的隔离运行环境，线上环境就是开发环境，减少了因二者差异导致的不确定性。一台机器可以部署成百上千个容器，如何让容器启动更快内存使用更少就很关键了。
有两个小小的改进值得注意：
- OPEN_TREE_NAMESPACE（由 Christian Brauner 开发）可将容器创建速度提升 40%。基准测试显示，旧的 pivot_root() 方法在 60 秒内大约创建 73,000 个容器，而新的 open_tree() 方法在相同时间内大约创建 109,000 个容器。如果运行的是拥有数百个节点的 Kubernetes，这将直接影响 Pod 启动时间；
- EROFS 新增了对容器共享页面缓存的支持。现在，跨容器具有相同哈希值的文件共享一个缓存副本。由于容器环境大多数镜像都基于相同的文件层 (layers)构建，这会大大减少内存用量。
Btrfs 文件系统实现了对大数据块直接 I/O 操作，这在以前是不可能的。数据库、视频处理和科学计算都直接受益。
7. 对AI代码如何合并进内核有了明确规则
Linux 内核由成千上万的志愿者和公司员工构建，他们提交的代码需要经过其他人审查才能被合并。随着 ChatGPT 和 Claude Code 人工智能工具开始写代码，内核社区需要决定：人工智能能否提交代码？如果人工智能编写的代码破坏了某些功能，谁该负责？
v7.0对此有明确的规定：
必须使用“Assisted-by”标签披露人工智能辅助。人工智能代理不得添加“Signed-off-by”标签，因为只有人类才能根据开发者原创性证书（Developer Certificate of Origin）合法地认证代码。
内核每次发布都会收到来自 200 到 250 家公司、1500 到 2000 名开发者的贡献。代码量超过 4000 万行（10 年间翻了一番），并且每两个月大约新增 40 万行。因此人工智能生成代码不可避免，制定官方政策既务实又必要。
2026年4月12日，Linus Torvalds正式发布了Linux v7.0 内核，这一重要里程碑为各Linux发行版维护者提供了清晰的技术起点，以便他们有序推进适配开发工作，并逐步向广大用户推送稳定版本。v7.0内核引入了多项具有战略意义的核心改进，涵盖硬件适配、文件系统增强、性能优化及安全性提升等关键领域。
首先，v7.0强化了对新一代硬件平台的适配能力，包括针对英特尔Nova Lake处理器的深度优化支持，新增图形、音频及 LPSS 驱动适配。此外，还进一步完善了对英特尔Crescent Island AI 推理加速器的深度支持，为未来高性能计算设备提供更出色的兼容性与效率提升。
在AMD硬件方面，v7.0优化了Radeon图形处理性能，正式启用了全新的 Radeon 图形 IP 块，并为即将推出的 AMD Radeon 新一代硬件提供了初始适配支持。这些硬件层面的改进，将有力释放新一代服务器、工作站及笔记本电脑的性能潜力。
此外，XFS文件系统完成了全面升级迭代，不仅实现了显著的性能提升，还新增了先进的自主自我修复机制。该特性引入了 xfs_healer 守护进程，由systemd管理，可实时监控元数据故障与 I/O 错误，并在文件系统保持挂载状态下自动触发修复流程，进一步巩固了数据完整性与系统可靠性防线。
这些改进让 v7.0 在企业级存储与高负载场景中具备更强的市场竞争力。与此同时，内核还标准化了通用 I/O 错误报告机制，大幅提升了故障诊断与系统恢复效率。
英特尔 TSX 事务同步扩展默认切换至“自动”模式，为支持该功能的 CPU 带来开箱即用的性能增益；AMD EPYC 平台则通过调度器可扩展性增强、内存管理策略优化，实现了多项显著性能收益。
其他值得关注的特性包括：EXT4 文件系统在并发直接 I/O 写入场景下的性能大幅优化、BTRFS 新增实验性 remap-tree 支持、io_uring 新增 cBPF 过滤器增强功能，以及针对 ARM64、RISC-V 及 LoongArch 等架构的架构级深度改进。这些特性共同彰显了 Linux 内核在硬件前瞻性支持、系统稳定性及开发效率上的持续演进能力。
据悉，Arch Linux 和 Fedora 等以更新迅速著称的发行版，将成为较早向用户推送 v7.0 更新支持的先行者。需要强调指出的是，普通用户切勿自行编译或安装最新内核，以免引发系统无法启动、兼容性异常等风险。正确做法是耐心等待各发行版维护者完成针对自身版本的全面优化与严格测试，再通过官方软件源或更新渠道执行安全升级。
如果用户现有系统已能稳定运行日常任务，无需急于追求最新内核版本。该版本的核心价值，主要体现在为此前未获得官方支持的新硬件提供及时、可靠的驱动适配支持，助力用户更快体验到最新硬件技术的优势。
总体而言，v7.0 的发布不仅标志着Linux 内核开发进入全新阶段，更凸显了开源社区在技术创新与稳定平衡方面的卓越实力。未来，随着 AI 辅助开发技术的持续深化，Linux 生态有望迎来更高效、更高质量的演进，为全球用户提供更加强大、稳定且可靠的操作系统基础。
开始移除对俄罗斯Baikal处理器的支持
2026年4月中旬消息，Linux 7.1 内核不仅启动了对 Intel 486 处理器支持的淘汰进程，也开始从内核中移除用于支持俄罗斯 Baikal 处理器的平台与驱动代码。 Baikal 曾被寄予厚望作为俄罗斯以本土处理器替代 Intel 与 AMD 芯片的主要方案。 起初 Baikal 规划采用 Arm 架构，随后转向 MIPS，多年之后又重新转回基于 ARM 的设计。
在过去十年中，Baikal 平台的部分支持代码陆续进入了 Linux 主线内核，但随着俄乌战争的爆发，后续推进工作被大幅削弱乃至中断。
2024 年起，一些与俄罗斯存在关联的内核维护者被移出维护名单，理由是出于合规性要求，其中包括负责 Baikal CPU 支持的部分俄罗斯 Linux 开发者。与此同时，由于制裁措施，Baikal 无法再委托台积电（TSMC）代工生产芯片，企业自身也最终走向破产。目前外界有关于“新 Baikal 项目”的零星消息，称可能会基于 RISC-V 内核重启，但信息极为有限，而且在制裁背景下未来由谁来承担芯片制造仍属未知；这一新动向与当前 Linux 内核中既有的 Baikal 支持被视为两个相互独立的问题。
在 Linux 7.1 中，缺乏维护、且出货量在俄罗斯国内都相当有限的 Baikal 平台代码开始被清理。最新合入主线的一项 ATA 子系统变更，已经移除了部分 Baikal 相关绑定，理由是该 SoC 的上游合入流程“不会最终完成”。此外还有更多删除 Baikal 支持的补丁处于排队状态，其核心理由是“Baikal SoC 与平台支持无法完成最终定稿，现有陈旧代码应予移除”。
对于当前仍在使用 Baikal 硬件的用户来说，主线内核中仍保留相关支持的版本是 Linux 6.18 LTS，继续停留在该长期支持版本上仍可维持现有功能。随着 Linux 7.1 的推进，内核在清理历史包袱和淘汰缺乏维护、实际部署极少的平台方面再进一步，而 Baikal CPU 支持的退出，也在某种意义上为这条试图以本土处理器替代国外 x86 芯片的道路画上了一个阶段性句号。
历时四年：Linux终于搞定NTFS原生读写，共计3.6万行代码
2026年4月下旬消息，Linus Torvalds已将全新的NTFS文件系统驱动程序并入Linux 7.1版本主线，Linux系统从此具备原生NTFS读写能力。据Phoronix报道，新驱动在多线程写入性能上提升35%至110%，挂载4TB等大容量硬盘的速度提升4倍。此前Linux对NTFS的支持长期存在短板，早期原生驱动仅支持只读，功能极其有限；Paragon Software提供的NTFS3驱动虽填补了空白，但多年进展停滞，稳定性和维护均存在问题。
新驱动的开发者Namjae Jeon曾为Linux开发exFAT驱动，此次耗时四年完成了超过3.6万行代码的NTFS驱动，已取代旧有方案。新驱动采用现代化代码架构，整合了IOmap和folio等Linux内核新技术，能有效降低数据损坏风险，未来在Linux环境下进行NTFS磁盘检查（fsck）与维护将更加便捷。Linus 对这份贡献表示高度认可，称之为Linux系统的"NTFS复活"，对于需要在Linux与Windows之间切换或共享数据的双系统用户而言，这是近年来最重要的内核更新之一。
诞生至今已有41年，v7.2内核将移除苹果AppleTalk协议
据科技媒体 Phoronix 2026年6月中旬报道，Linux 上游开发者已决定将苹果 AppleTalk 协议从 7.2 内核中彻底删除，移除近 4000 行源代码。
AppleTalk 是苹果 1985 年发布的一套专有通讯协议，诞生至今已有 41 年。它能够在局域网环境中，为 Macintosh 电脑提供简易的自动发现和联网功能。不过从 20 世纪 90 年代起，标准化的 TCP / IP 协议全面普及，AppleTalk 已在过去二十年间逐步退出历史舞台，苹果也已经在 2009 年放弃支持该协议。
负责维护 Linux 网络子系统的开发者 Jakub Kicinski 在移除代码说明中写道：“根据维基百科信息，AppleTalk 已经从 2009 年起随 Mac OS X 10.6 移除。近期我们收到了大量 AI 生成、针对该协议的修复补丁，但根本没人审查”。因此开发团队决定将 AppleTalk 与其他被淘汰的网络协议扫出 Linux 主线内核。就让 AppleTalk 像 AX.25 和业余无线电一样，从 Linux 代码库中移除吧。将通过 github.com/linux-netdev/mod-orphan 维护该代码，供任何有兴趣尝试的人使用。暂时先保留 uAPI。没有特别的理由，只是觉得保留它会减少争议。在 Linux 7.1 的前一个内核周期中，Linux 还取消了对旧 ISA 和 PCMCIA 硬件的 ARCnet 支持，并移除了 ISDN、业余无线电和其他旧的网络驱动程序，所有这些移除举措均源于近期因 AI/LLM 相关补丁大量涌入而引发的调整。
AppleTalk 协议是苹果公司为其 Macintosh 计算机开发的专有网络协议套件，于 1985 年随 Macintosh 系统发布，主要用于局域网内的文件和打印机共享。在 Linux 7.2 内核之前，Linux 内核已计划移除另一个源于微软 Windows XP 时代的古老协议 USB RNDIS，该协议同样因存在安全漏洞且不再必要而被提议移除。
Linux v7.2 消灭了一个 C 标准库函数 strncpy，这场迁移照出了 C 语言在系统编程中的结构性安全债。
v7.2 合并窗口期一条看似平淡的提交引起了人们的注意：内核中所有 strncpy() 调用已被移除。这项工作的标题是"Linux Finally Eliminates The strncpy API"，耗时六年，涉及 360 多个补丁，触及内核的数百个位置。对于非 C 程序员来说，这听起来像一次无害的重构。但对于了解 C 语言字符串处理历史的人来说，这是一场审判的终局判决。
strncpy 的问题源于设计，不是一个意外 bug
strncpy(dst, src, n) 的行为描述只有一句话：从 src 复制最多 n 个字符到 dst。如果 src 的长度小于 n，剩下的空间用 \0 填充。如果 src 的长度大于或等于 n，dst 不会被 null 终止。
第三条是最致命的。它意味着任何在 strncpy 之后直接使用 dst 的代码——比如 strlen(dst)、printf("%s", dst)——都在赌 src 的长度严格小于 n。这个赌注在内核中尤其危险：内核中的缓冲区大小通常由配置、硬件描述符、或用户输入决定，长度约束在编译期不可见。
更隐蔽的问题是"填充直到 n"行为。如果缓冲区是 4KB，而 src 只有 16 个字节，strncpy 会把剩余的 4080 个字节全部写成 \0。这在热路径上是纯浪费，在内核中可能意味着一次不必要的 TLB flush。
这两个问题都源于设计——它们是 API 行为定义的一部分。strncpy 最初的设计场景是复制到固定宽度的、以空格填充的文本字段（Unix 早期文件系统的目录条目）。当 C 标准委员会在 1989 年把它纳入 ANSI C 时，这个 API 已经被大量代码复用到了它从未被设计过的场景中。
从 strlcpy 到 strscpy：二十年中的两次纠正
第一次纠正发生在 1998 年。OpenBSD 的 Theo de Raadt 和 Todd C. Miller 设计了 strlcpy(dst, src, size)，它保证 null 终止、不填充、返回 src 的总长度（用于检测截断）。Linux 内核在 2.6 时期广泛引入了 strlcpy。
但 strlcpy 有一个微妙的问题：它读取 src 的全部长度来计算返回值，即使只复制前几个字节。如果 src 指向一个不受信任的、非 null 终止的字符串，这本身就是一次越界读取。
第二次纠正是 Linux 自己的解决方案：strscpy(dst, src, count)。它在 2015 年被合入内核，限制读取长度为 count、保证 null 终止、返回复制的字节数或 -E2BIG（截断错误）。这是 C 语言在现有类型系统内能做到的最安全的字符串复制。
从 strscpy 被引入到 strncpy 被完全消灭，中间经历了六年。瓶颈不在于技术——strncpy 到 strscpy 的转换在大多数情况下是机械的——而在于审查。每一处替换都需要确认：原来的 strncpy 是否依赖了"填充到 n"的副作用？下游代码是否隐含地假设了 dst 的末尾填充？是否有代码读取到了填充区域并期望它全是 \0？
360 多个补丁，每一个都在回答这些问题。最慢的不是写代码，是证明代码没有悄悄依赖那个要被删除的 API 的未定义行为。
Rust 的镜像：这些 bug 在编译期就死了
这场迁移最尖锐的旁注来自 Rust。在 Rust 中，字符串切片 &str 永远是有效的 UTF-8、永远以长度标记而非 null 结束符为边界。不存在"复制 n 个字节后忘记 null 终止"的余地——类型系统不允许。也不存在"忘记检查截断"的余地——copy_from_slice 的源和目标长度不匹配时是编译错误。
Rust 同样有安全问题——unsafe 块中的裸指针操作和 C 一样危险。但区别在于：在 C 中，整个内核都是 unsafe 块。在 Rust for Linux 中，安全边界被收缩到了明确定义的 FFI 接口和少数核心抽象中。
Linux 内核社区对 Rust 的接纳速度很慢——截至 2026 年中，Rust for Linux 仍然只覆盖了少数驱动子系统。但 strncpy 的消灭提供了一个具体的参照点：一个 API 在引入 37 年后才被彻底移除，期间产生了无数安全漏洞。如果 Rust 中一个等价的错误模式被编译器拒绝，那么用 Rust 写的内核代码就不会有这种延迟。
2026年8月中旬消息，Linus Torvalds正式发布了Linux 7.2稳定版内核。该版本历经9周开发周期，代码行数突破4300万行，成为近年来更新规模最大的内核版本之一。
AMDGPU驱动首次引入对HDMI 2.1 FRL（固定速率链路）的初步支持，为AMD显卡用户在新版本Linux上实现4K高刷新率与8K显示输出铺平了道路。另外 AMD ISP 4（图像信号处理器）驱动也同步并入主线。
英特尔Xe显卡驱动新增对CRI平台的初始适配，并合入了对英特尔Nova Lake平台HDMI输入采集功能的支持。此外，USB4STREAM协议也正式合入主线，支持通过USB4或雷电接口实现低延迟数据包传输。
缓存感知调度是本次更新的核心亮点之一，经过一年多的开发终于正式合入。该功能允许CPU调度器感知各级缓存拓扑，将相关任务调度到共享缓存的核心上运行，有效提升缓存命中率与多任务处理效率。
其他硬件更新方面，瑞昱USB万兆网卡RTL8159获得主线支持。
本次更新还包含多项重要改进：bpf()系统调用支持通用属性、Btrfs文件系统引入大页支持、ext4文件系统性能提升、Landlock安全模块增强、块设备内联加密支持、RISC-V架构默认CPU核心数上限从64提升至256、移除对老旧i486及PCMCIA硬件的支持。
LWN分析显示，约5%的代码提交带有"assisted-by"标签，表明AI工具在开发过程中发挥了作用。该版本已可在kernel.org下载，Ubuntu26.10等发行版预计将默认搭载该内核。
Linux v7.2 在进程调度、文件系统、网络、虚拟化、内存管理、安全以及硬件支持等多个方面带来了大量改进，同时也进一步清理了一批已经过时的硬件支持和内核代码。与此前版本相比，v7.2 并没有集中在某一项重大功能上，而是对内核的多个核心子系统进行了持续优化。这些变化虽然不少属于底层技术，但对于服务器、桌面电脑、虚拟机以及各种嵌入式设备来说，都有望带来更好的性能、稳定性和硬件兼容性。
调度器迎来缓存感知优化
v7.2 在进程调度方面加入了缓存感知型负载均衡机制。简单来说，内核现在会更加关注不同 CPU 之间的缓存关系，在进行任务调度时，尽量让共享缓存资源的进程继续运行在相同的 CPU 缓存域中。这样可以减少进程频繁在不同 CPU 之间迁移所产生的缓存失效和数据重新加载开销。对于部分对缓存敏感的工作负载来说，这项改进有望进一步提升整体运行效率。
内存与文件系统持续优化
内存管理同样获得了一系列改进。持续重构中的 swap 子系统进一步统一了匿名 folio 和共享内存 folio 的处理方式，同时降低了自身运行所需要的内存开销。开发人员表示，相关静态元数据带来的额外开销已经接近于零，部分工作负载的性能也得到了一定提升。
文件系统方面，Btrfs 成为了 v7.2 的重点改进对象之一。大 folio 现在默认启用，并新增了最大 2 MB folio 的支持，不过后者目前仍属于实验性功能。XFS 的分区存储支持也进一步成熟，这项功能最初在 v6.15 中加入，如今已经不再被标记为实验状态。
存储子系统还新增了 dm-inlinecrypt Device Mapper 目标，主要用于支持内联加密功能的块设备。NFS 则将默认传输块大小提升至 4 MB，不过这一调整只会应用于内存容量至少达到 16 GB 的系统。
此外，内核中的 SMB 服务器现在支持以压缩形式存储文件，并可以对通过网络传输的数据进行压缩。NTFS 也进一步增强了磁盘元数据损坏防护能力，同时增加了对 Windows 原生符号链接的支持。
网络与 BPF 获得多项增强
网络子系统也迎来了不少变化。MultiPath TCP（MPTCP）的子流数量上限从此前的 8 个提升至 64 个，对于需要通过多条网络路径进行数据传输的应用来说，这意味着更大的扩展空间。与此同时，Linux 开发人员仍在持续减少网络子系统对全局 rtnl_lock 的依赖，以降低大型系统中的锁竞争，并进一步改善网络子系统的扩展能力。
BPF 同样获得了一系列更新。BPF 哈希映射现在可以采用可动态调整大小的实现，不再需要在创建时固定桶数量。此前 BPF 函数和 kfunc 最多只能使用 5 个参数，这一限制也被取消，现在可以通过栈传递更多参数。此外，同一个 BPF 程序现在能够更加高效地附加到多个 tracepoint，为性能分析、监控和安全工具开发提供了更大的灵活性。
KVM 虚拟化能力进一步提升
虚拟化方面，KVM 新增了对 Intel Mode-Based Execution Control（MBEC）和 AMD Guest-Mode Execution Trap 的支持。这些技术可以帮助虚拟机更加精细地控制代码执行权限，并减少虚拟机在处理权限相关操作时频繁进入宿主机的情况，从而改善虚拟化环境的运行效率。
针对 Intel TDX 系统，v7.2 还加入了管理 TDX 软件模块的基础设施，其中包括在系统运行过程中替换 TDX 模块的能力，为机密虚拟机环境提供了更加灵活的管理方式。
Rust 支持继续扩大
Linux 内核对 Rust 的支持也在不断推进。v7.2 将 IBM s390 架构加入到可以构建 Rust 内核代码的架构列表中，这意味着 Rust 在 Linux 内核中的应用范围进一步扩大。与此同时，内核源码树中还加入了 Rust zerocopy crate，为内存数据处理提供低成本的基础功能，同时有助于减少不安全代码的使用范围。
安全功能进一步加强
安全方面，Landlock 获得进一步扩展，现在可以限制 UDP 套接字的使用，为应用程序提供更加细粒度的网络访问控制能力。
Integrity Measurement Architecture（IMA）也新增了从内核内存中导出并删除测量数据的能力。对于长期运行并积累大量测量记录的系统来说，这项改进可以帮助释放内存资源。
清理过时硬件与旧代码
除了增加新功能之外，v7.2 也继续进行内核代码“瘦身”。开发团队进一步清理了多年以前遗留下来的旧硬件和架构支持，其中一个比较明显的变化，就是删除了超过 13,000 行用于没有硬件 FPU 处理器的浮点运算模拟代码。
PowerPC 架构中针对特定硬件优化的 MD5 实现也被移除。同时，一些已经较少使用的网络硬件和协议支持也被清理，包括部分 ISA 和 PCMCIA ARCnet 设备、老旧的 PCMCIA 蓝牙适配器、更多 ATM 相关代码以及 AppleTalk。
此外，AF_ALG 机制已经被标记为弃用，未来可能会从 Linux 内核中彻底移除。
新增 SBOM 生成功能
对于需要自行编译 Linux 内核的开发者来说，v7.2 还加入了一项比较实用的新功能，现在可以通过 make sbom 命令生成与当前内核配置对应的 SBOM，也就是软件物料清单。该功能会利用 Linux 内核源码中的 SPDX 信息，只把当前配置下实际参与编译的文件纳入清单，因此生成的 SBOM 能够更加准确地对应最终构建出来的内核。
与此同时，构建 Linux 内核所需的最低 LLVM 版本也提升至 LLVM 17.0.1。
硬件支持更加丰富
硬件兼容性一直是 Linux 内核更新的重要内容，v7.2 也带来了大量新的硬件支持。此次更新涵盖无线网卡、游戏掌机、数位板、图像处理器以及各种传感器和 SoC 组件，为新设备提供了更好的支持。其中包括：
Realtek 8922AU USB 无线网卡、Virtio CAN 接口、OneXPlayer 掌机控制器、新款 Wacom 设备、更多 AMD 图像信号处理器，以及 USB4STREAM 硬件，同时还增加了大量传感器、电源控制器、音频编解码器、SoC 组件和 PHY 等设备支持。
Linux Kernel 7.2 现已可以从 kernel.org 获取源代码。采用滚动更新模式的 Linux 发行版通常会较快将新内核加入软件仓库，而其他发行版则需要经过自身测试和打包流程，预计会在之后陆续提供更新。对于普通用户来说，没有必要为了追求最新版本而立即手动编译 v7.2。如果当前使用的 Linux 发行版已经提供经过测试的 v7.2 软件包，建议优先通过发行版官方软件仓库进行升级，这样通常能够获得更好的兼容性和稳定性。
总体来看，Linux v7.2 是一次覆盖面非常广的内核更新。它不仅改进了 CPU 调度、内存管理、Btrfs、网络、BPF 和 KVM 等核心组件，还进一步扩大了 Rust 支持范围，并加入 SBOM 生成功能。与此同时，v7.2 继续清理已经过时的硬件和历史代码，让内核保持更加精简和现代化。对于服务器、虚拟化平台、开发环境以及新硬件用户来说，这些底层改进都具有一定价值。
内存维护者Andrew Morton拟退休
2026年8月的Linux社区发生的一件事，却给出了另一个答案。一位66岁的维护者，宣布退休。奇怪的是，当他在邮件列表中发出这个消息的时候，几乎没有收到什么回应。不是没人理他，是没有一个人敢单独地接他的班！
这些Linux内核大牛们都搞不定，更别说AI了。原因很简单，他的工作实在太重要了！
全球的Android手机，云服务器、超级计算机、路由器、智能电视、机顶盒、嵌入式设备...... 都依赖他维护的代码 ：Linux 内存管理（Memory Management，简称 MM）；而这位名叫Andrew Morton的老人，已经在这个领域坚持了整整26年。
最难维护的子系统
内存管理有什么用呢？
这里举个简单的例子：当你打开电脑，再打开浏览器，再打开音乐播放器，再启动一个 AI 模型...... 这些程序都需要申请内存，内存管理需要决定：
什么时候分配？
什么时候回收？
哪些页面放在高速缓存？
什么时候交换到磁盘？
虚拟地址如何映射到物理地址？
NUMA、多核、Huge Page、页缓存、匿名页、内存压缩……
这些几乎全部属于内存管理的职责，它不像文件系统那样容易被看见，也不像网络协议那样容易调试。但只要它出一点问题，整个系统就可能卡死、崩溃，甚至数据损坏。所以在 Linux 内核里，一直流传着一句话：内存模块是最难维护的子系统之一。
mm模块一共有164个c源代码文件，如果你做一个快速搜索的话，就会发现像THP、cgroup、NUMA等术语在大量文件中出现，换句话说，核心的内存管理概念广泛分布在整个mm模块中，所有代码都紧密关联，试图拆分成更小的子系统将极具挑战性。
更可怕的是，mm模块负责虚实内存转换，涉及页表、缓存、回收和 swap 等复杂机制，同时又要在高并发和多子系统交互下保持正确性，这种高复杂度与 C 指针模型叠加，使得任何细微错误都可能直接导致内存破坏，从而成为内核漏洞的温床。
统计数据显示，mm模块的漏洞数约占20%左右，所以接手它绝对是一块儿烫手山芋。
26载的维护
Andrew Morton 1959年出生于英国，后来移居澳大利亚，在位于悉尼的新南威尔士大学学习电子工程。毕业后他和朋友合伙儿创办了一家公司 ，开发一个叫做Applix的个人电脑，Andrew不但设计了硬件，还开发了操作系统1616/OS ，积累了硬件和OS的经验。90年代中期，他注意到了Linux，开始向 Linux 内核提交补丁，最初专注于内存管理等领域。
这时候Linux逐渐进入企业级市场，当内存越来越大，CPU越来越快，尤其是数据库开始大量运行在Linux上时，Linux出了问题：在高负载情况下，虚拟内存表现太糟糕了，导致服务器频繁锁死或陷入 Swap 抖动。
当时 Linus 甚至在 2.4.10 临时用 Rik van Riel 的新 VM 替代了原有的 VM，引发了社区大地震。
危急时刻，Andrew Morton 出手了， 他凭借高超的工程能力，连续提交了大量极其务实、极其高效的 Patch，疯狂修补和重构了 Page Cache、Writeback（回写）和 LRU 算法。
他不仅持续提交补丁，更重要的是，愿意花大量时间审查别人的代码、协调不同开发者之间的分歧。
这种能力很快引起了 Linus Torvalds 的注意。Linus 后来评价 Morton 最大的优点，不是代码写得最快，而是能够“与别人很好地合作，并始终保持理智。”
随着 Linux 后续开发周期的推进，Linus 一个人确实无法处理海量的补丁，Andrew 顺势建立了 -mm Tree。
从名称看，这个源代码tree是为了内存管理的，但实际上，它很快演变成了 Linux 内核的“试验田”和“前置缓冲区”。
很多实验性的 Kernel Patch，都会先进-mm Tree，这些补丁先接受 Andrew 的测试和社区的反馈，稳定后再由 Linus 合入主线（Mainline）。
Linus 曾多次公开表示，如果一个补丁被 Andrew 看过并签名，他几乎会闭着眼睛合并。给一个补丁做签名相当于给别人贷款做担保，你是在别人的工作成果上签了名，并声明：我审核过，我信任这个补丁，如果这个补丁导致十亿台设备出现生产环境问题，我的名字要承担责任。
到 2007 年，Andrew已签署了 18,622 个补丁，仅次于托瓦尔兹本人，后者签署了 19,890 个补丁，可见 Andrew 在Linux社区的责任巨大。
实际上，Linux 内核社区聚集着不少世界级工程师，但问题在于：没人拥有Andrew 那样完整的知识体系。二十六年的代码，无数历史设计，数不清的兼容性，各种架构之间的微妙关系。很多东西，代码里没有写，文档里也没有写，只有 Andrew 自己知道。
在软件工程中有一个概念：Bus Factor（公交车系数）。
如果 Bus Factor = 1 ，整个项目只有一个人真正懂，这个人一离职、生病、休假，甚至只是去度假，项目就没人能维护了。
现在Andrew要退休了，mm社区经过讨论，达成的共识是：今天的mm太大了，再找一个"全知全能"的维护者是不现实的，必须要把职责进一步分散（增加Bus Factor）。
如果看下Linux社区的核心维护者：
Linus （总负责人） ： 56岁
Theodore Ts'o （ext4） : 58 岁
David Miller （networking） : 60岁
Thomas Gleixner（中断、Timer、PREEMPT_RT）：58岁
Al Viro（VFS）： 59岁
Greg Kroah-Hartman（USB, driver core, TTY）：58岁
他们中的很多人从 1992～1995 年 就开始给 Linux 写代码，已经持续维护了 30 多年！
他们没有流量，没有融资，也很少登上新闻。但如果没有他们，今天我们熟悉的互联网，可能根本不会是现在这个样子。
在过去30多年里，Linux 社区对“Linus 如果不在了怎么办”一直讳莫如深，Linus本人的态度曾长期是“到时候自然会有人顶上”。
但随着核心团队日益老龄化，2026年1月，内核社区终于合并了一份里程碑式的官方连续性文档：《Linux项目延续性文件》：该文件明确规范了当Linus Torvalds或核心团队无法继续工作时，如何无缝选举和移交最高主仓库的合并权限。这是 Linux 历史上第一次承认“人终有一死”并建立制度化交接。
很多人担心：AI 会不会取代程序员？
但Linux社区真正担心的问题却是：Andrew Morton 退休以后，谁来维护 Linux 内存管理模块？
一个担心的是写代码的人越来越少；一个担心的是懂系统的人越来越少。
这两个问题，恰恰代表了软件工程里最容易和最困难的两件事情。AI 能生成代码，但还生成不了Andrew Morton 身上那二十六年的工程智慧。
AMD核显大爆发-Linux 7.4默认启用HDMI 2.1：性能最高涨23%
2026年10月上旬消息，AMD近日向DRM-Next提交了新一轮AMDGPU内核图形驱动更新，为即将到来的Linux 7.4合并窗口做最后准备。本次更新以修复为主，同时包含多项新硬件IP块启用和HDMI 2.1功能完善。
新硬件IP块支持是本次更新的核心看点。AMD为多个即将推出的GPU IP模块添加了启用支持，包括OSSSYS 8.0.1、LSDMA 8.0.1、NBIF 7.10、SMUIO 15.0.3、MP 15.0.3、VPE 3.0和MMHUB 5.0。
其中VPE 3.0是视频处理引擎IP的一次重大版本升级。此外，Display Core Next DCN 6.0、AMD GFX12.1和SMU 15等此前已添加的IP块也获得了进一步更新。
HDMI 2.1支持是Linux 7.4最受期待的功能。AMD于9月10日向DRM-Next提交了功能拉取请求，首次将HDMI FRL（固定速率链路）从默认禁用改为默认启用，并新增HDMI 2.1 FreeSync、VRR和ALLM支持。
此前HDMI 2.1 FRL虽已在Linux 7.2中合入，但默认处于关闭状态，AMD等待VRR等功能完备后才启用，以避免用户功能回退。
HDMI Forum此前一直拒绝为开源Linux驱动提供HDMI 2.1许可，转机出现在2026年，Valve与AMD合作推进的补丁陆续进入内核邮件列表。
PerfOpt性能优化补丁是本次更新中针对核显用户的重大利好。该补丁允许集成GPU在直接访问系统内存时绕过IOMMU的地址转换，IOMMU仅执行权限位检查，不再进行GPA到SPA的地址转换，从而减少核显访问内存时的系统开销。
据Phoronix测试，在Strix Halo APU设备上，本地大模型性能最高可提升18%至23%。该特性由驱动主动启用，用户也可通过模块参数强制禁用。
本次拉取请求还包含多项修复，覆盖dc_state_create_copy、HDMI RGB有限范围、eDP ASSR、DCE 6/8.1、SI DPM、GPUVM、Switcheroo、SDMA 7.1、DP MST、DCN 6以及MacBookPro14,3等具体平台问题。
AMDKFD计算驱动同步获得SVM修复和重置修复，旧的Radeon内核驱动甚至为Sun/Oracle SPARC64硬件添加了兼容性修复。