Linux 7.3-rc2 在北京时间 9 月 7 日凌晨发布。它不是稳定版，也不是一次面向普通用户的功能升级，而是 Linux 7.3 开发周期中的第二个候选版本。
对大多数桌面用户来说，现在没有必要为了追新版本替换正在使用的内核。对内核开发者、发行版维护者、硬件驱动作者和运行自定义内核的团队来说，rc2 却是一个值得拿来做回归测试的时间点：第一轮合并已经过去，接下来更重要的是确认驱动修复、并发修复和子系统调整没有破坏已有行为。
rc2 到底意味着什么
Linux 的开发过程通常先进入合并窗口，接纳新功能和大块改动；合并窗口关闭后，内核进入候选版本阶段。候选版本主要用于修复回归、完善边界情况和稳定已有代码，版本号从 -rc1、-rc2 逐步向正式版靠近。
这次 v7.3-rc2 与 v7.3-rc1 相隔约一周。kernel.org 将它标记为 mainline 测试版本，并提供了完整源码包，以及从 v7.3-rc1 到 v7.3-rc2 的增量补丁。Linux 主仓库的比较结果显示，这一周合入了 681 个提交；这个数字描述的是代码集成规模，不等同于 681 个面向用户的新功能。
因此，读 rc2 的正确方式不是问“它增加了什么杀手级特性”，而是问：
- 哪些硬件和子系统的旧行为刚刚被修正？
- 我的工作负载是否覆盖这些变更的边界？
- 如果出现回归，我能否把问题缩小到某个版本或提交？
从比较结果里能看到哪些修复方向
候选版本没有一份像稳定版那样面向普通用户的功能清单。结合内核主线的比较记录，可以看到本轮包含存储、跟踪、BPF、音频、显示和文件系统等方向的修复。下面几类变化很适合作为测试切入点。
存储：限制 NVMe 请求，避免 PRP 链越界
megaraid_sas 驱动修正了 NVMe 请求大小与 PRP 链帧容量之间的关系。此前，块层的默认最大请求大小变化后，一次请求可能需要更多 PRP 表项；当这些表项超过驱动分配的帧边界时，可能出现越界写入。
这类问题有两个麻烦之处。第一，硬件和请求大小必须同时满足条件，普通磁盘读写不一定马上触发。第二，越界区域如果刚好映射到可写内存，系统可能不会立刻崩溃，而是先悄悄破坏相邻对象。
如果团队使用 MegaRAID 控制器、NVMe 后端或高吞吐存储，测试不能只做一次启动和简单的文件复制。更有价值的组合是：
- 大块顺序读写与随机读写；
- 多队列并发 I/O 和长时间压力测试；
- 文件系统检查、重启和设备异常恢复；
- 对比 rc1、rc2 与当前稳定内核的 dmesg、I/O 错误和延迟。
这类修复也提醒驱动作者，块层默认值变化后，驱动内部对请求大小的假设必须重新检查。一个上游看似通用的容量调整，可能让下游硬件路径暴露出此前没有遇到的边界。
跟踪：初始化顺序和对象生命周期仍然是高风险区域
本轮比较中还包含 ftrace 初始化同步以及 trace 选项文件引用生命周期方面的修复。内核跟踪系统会被调试工具、性能分析器和生产诊断脚本同时使用，许多问题只在“一个线程打开文件、另一个线程移除实例”的并发场景中出现。
这类修复的测试重点不应只是“能不能打开 tracing”。更适合做压力循环：反复创建和删除 trace 实例，同时启停事件、读取 options 文件，并让多个线程并行执行。测试结束后还要检查是否出现 use-after-free 报告、锁依赖告警、软锁死或异常的引用计数。
内核调试功能有一个常见误区：平时不用，就以为相关代码不会影响系统。实际上，跟踪接口常常与调度、锁和对象生命周期相连；即使业务程序没有主动启用它们，内核配置和模块加载方式仍可能改变执行路径。
BPF：验证器修复不能只看“程序能否加载”
BPF 相关提交修正了回溯分析在处理回调时清理外层寄存器状态的问题，并补充了对应的自测试。BPF 验证器的工作不是运行一段程序后再观察结果，而是在加载前分析寄存器、栈和控制流，证明程序满足安全约束。
验证器的一个小错误，可能导致两种相反的结果：合法程序被错误拒绝，或者本来应该保留的状态被错误清除，导致分析结果不可靠。后者尤其需要谨慎，因为“程序成功加载”并不等于验证器覆盖了所有应有的路径。
使用 BPF 的团队应把自测试、实际程序和内核版本一起纳入矩阵。可以重点覆盖 bpf_loop()、回调、尾调用、map 访问和不同 JIT 架构，观察加载结果、验证日志和运行时行为是否一致。不要只在 x86_64 上通过后就认为其他架构也没有问题。
音频与显示：硬件回归往往只发生在特定组合
候选版本还包含 Realtek HDA 针对特定 Acer Aspire A515-57G 机型的冷启动耳机检测修复，以及 AMD 显示混合模式属性相关调整。这种补丁看起来很窄，却是内核维护中很重要的一类工作：同一套驱动代码在不同 PCI 标识、固件版本、启动顺序下可能走不同分支。
对硬件厂商和发行版维护者来说，测试表不能只写“音频正常”“画面正常”。更具体的检查包括：
- 耳机在冷启动前已插入、系统启动后再插入，两种情况分别验证；
- 休眠、恢复、重启和切换输出设备；
- 多显示器、不同刷新率和显示器热插拔；
- 记录 PCI ID、固件版本、桌面协议和内核配置。
当问题只在冷启动或恢复路径中出现时，用户很难用一句“偶发”描述清楚。测试记录越具体，内核开发者越容易复现和定位。
为什么候选版更适合做回归测试
候选版的意义，在于它把“新功能快速合入”和“行为稳定下来”分成了不同阶段。到了 rc2，开发者已经可以围绕相对稳定的接口和配置开展测试，同时还有机会在正式版前反馈问题。
这对不同角色的价值不一样：
| 角色 | 关注点 | 适合的动作 |
|---|---|---|
| 驱动作者 | 设备初始化、请求边界、并发和错误恢复 | 在真实硬件上跑定向压力测试 |
| 发行版维护者 | 配置、模块、安装和升级 | 用发行版配置构建并跑自动化测试 |
| 云平台或基础设施团队 | I/O、网络、eBPF 和监控 | 在隔离节点进行工作负载回放 |
| 普通桌面用户 | 外设、图形、休眠和音频 | 等待发行版打包或稳定版发布 |
候选版本不适合直接替换生产内核，除非团队已经有完整的启动回滚、节点隔离和监控机制。测试的目标是尽早发现问题，不是为了让生产环境承担验证成本。
一套可执行的 rc2 回归流程
1. 先保留可回滚入口
在测试机器上保留当前稳定内核，并确认引导菜单可以选择旧版本。云主机或裸机环境还要确认远程控制台、串口或带外管理可用。内核测试最怕“升级成功，但无法远程进入机器”。
2. 用现有配置生成最小变更
尽量从正在运行的内核配置开始，使用 make olddefconfig 处理新增选项，再编译 rc2。这样出现差异时，问题更可能来自候选版本身，而不是同时更换了大量配置。
常见流程可以写成：
1 | cp /boot/config-$(uname -r) .config |
这只是构建示例，安装和启动方式应按发行版的打包策略执行。不要在不了解引导配置的情况下直接覆盖生产内核。
3. 让测试贴近真实工作负载
存储团队应回放真实 I/O 模式，BPF 团队应使用真实程序和自测试，桌面团队应覆盖冷启动、休眠和外设热插拔。单纯执行 uname -r 或成功启动，只能证明内核能启动，不能证明变更没有影响业务。
4. 对比三个版本
至少保留稳定版、rc1 和 rc2 的测试结果。对比启动时间、系统调用错误、I/O 延迟、网络吞吐、功耗、dmesg 警告和测试失败项。这样可以判断问题是在 rc1 已经出现，还是 rc2 新引入，避免把旧问题误报成新回归。
5. 报告问题时给出可复现条件
一份有用的内核回归报告，应包含内核版本和提交、硬件型号、固件、发行版、配置文件、复现步骤、预期与实际结果，以及必要的日志。对这次 rc2 来说，说明问题是否只出现在特定队列深度、启动顺序、BPF 程序或显示器组合中，比一句“升级后坏了”更有帮助。
该不该现在升级
可以按使用场景做判断：
- 内核开发者和驱动作者： 值得在测试机上跟进，尤其是存储、BPF、跟踪、音频和显示相关项目。
- 发行版维护者： 可以开始构建和跑自动化回归，为后续稳定版打包做准备。
- 基础设施团队： 只在隔离节点或灰度环境验证，不要把候选版直接铺到整个集群。
- 普通桌面用户： 没有明确问题需要验证时，继续使用发行版提供的稳定内核更合适。
rc2 的发布不代表 7.3 已经完成，也不代表所有问题都已修复。它提供的是一份更接近正式版的测试材料，以及一个让问题在稳定版之前被看见的窗口。
结语
Linux 7.3-rc2 的价值不在于“今天多了哪些功能”，而在于它让内核生态进入了下一轮验证阶段。存储请求边界、跟踪对象生命周期、BPF 验证器状态和特定硬件启动顺序，都说明稳定性往往藏在很窄的路径里。
如果你的项目依赖自定义内核、eBPF、特定存储控制器或复杂外设，今天可以做的事情很具体：保留可回滚内核，用现有配置构建 rc2，回放真实工作负载，并把稳定版、rc1、rc2 的结果放在一起比较。候选版不是用来炫耀版本号的，它的作用是让下一次正式发布少一些意外。