Linux 7.3 已正式发布。上游版本提交时间为 UTC 2026 年 10 月 18 日 23:14，对应北京时间 10 月 19 日早上。这次不罗列整版新功能，单看其中一个直接影响虚拟化用户的修复：部分 Samsung 990 PRO 和 990 EVO Plus SSD 宣告支持“立即就绪”，实际复位后却还不能马上访问。
问题出在 PCIe 配置恢复的时序上，已经有 VFIO 设备直通失败的报告。修复没有关闭整块硬盘的复位功能，而是让内核不再相信这两类设备宣告的 Immediate Readiness 能力，恢复必要的等待。
硬盘平时可用，不代表复位后也已经准备好
把 NVMe 设备直通给虚拟机时，宿主机需要在设备生命周期中处理复位、重新配置和交接。FLR，即 Function Level Reset，是 PCIe 的功能级复位机制。
复位发出后，软件不能总是假设设备立即接受后续配置访问。Immediate Readiness 能力给了内核一条更快的路径：设备如果宣告支持，内核可以跳过通常的复位后等待。
上游修复说明指出，Samsung 990 PRO 的某些固件虽然宣告了这项能力，FLR 后的配置读取却会在最长约 7 毫秒内返回全一值。这里的异常来自 PCI 配置访问，不是说用户数据读出来都变成了全一，也不能据此判断闪存已经损坏。
真正触发故障的是后续配置恢复发生得太早。之前的提交 10baa9b4df40 移除了恢复 BAR 时不必要的重试；设备尚未就绪时，配置恢复没能生效，从而破坏了 VFIO 直通。
BAR 是 Base Address Register，用来描述设备寄存器等资源的地址映射。这个环节出错后，即便 SSD 日常存储读写正常，经过特定复位与重新分配流程仍然可能失败。
这也是硬件兼容性问题难查的一点：故障不一定在持续读写时发生，可能集中出现在虚拟机再次启动、设备重新交接或某次复位之后。
两个设备 ID，几个已报告的固件版本
补丁没有只按产品名称模糊匹配，而是在 PCI 层对两个设备 ID 设置兼容性处理。
| 设备 | PCI 厂商与设备 ID | 上游提交记录 |
|---|---|---|
| Samsung 990 PRO | 144d:a80c |
较旧固件如 1B2QJXD7 在 FLR 后不能立即响应；8B2QJXD7 则能立即响应 |
| Samsung 990 EVO Plus | 144d:a80d |
2B2QKXG7 被报告似乎有同类问题 |
这里需要保留提交说明中的强度。990 EVO Plus 的描述是“似乎有同样的问题”，不能把它扩写成对所有容量、所有固件的全面测试结论。
990 PRO 的新固件表现也不构成所有同型号设备都已经修好的保证。上游说明，执行这段 PCI 兼容性处理时看不到 NVMe 固件版本，所以补丁选择按设备 ID 处理，没有在这里再细分新旧固件。
如果你只在普通桌面环境使用这些硬盘，没有直通失败或复位异常，不必仅凭型号就断言机器已经受影响。应把设备 ID、固件、实际内核补丁与故障场景放在一起判断。
补丁做的是取消信任，不是禁止 FLR
核心修复位于 drivers/pci/quirks.c。它给上述两个设备注册了一个兼容性函数：如果设备宣告 Immediate Readiness，就清除内核中的 imm_ready 标志，并打印说明日志。
关键动作是：
1 | dev->imm_ready = 0; |
这不会给 SSD 刷写固件，也不是禁用 NVMe，更没有关闭整个 FLR 路径。它改变的是内核对设备复位完成速度的判断。
对照 Linux v7.3 的 pcie_flr() 可以看到，imm_ready 为真时会跳过等待；否则代码先等待 100 毫秒，再调用 pci_dev_wait() 检查设备就绪情况。因此，不能把报告中“最长约 7 毫秒不可访问”理解成补丁只增加 7 毫秒延时。
100 毫秒等待的注释依据是 PCIe 对 FLR 的时序要求。修复回到了更保守的标准路径，以避免在设备仍可能丢弃请求时开始配置访问。
这点延时发生在相应复位流程中，不是对每次文件读取或每个 NVMe 请求统一加延迟。讨论性能代价时，也应区分复位耗时和正常工作负载的吞吐量。
新版发布了，发行版有没有补丁要另外查
Linux 7.3 的最终版本包含这项修复，但生产系统不应只看 uname 中的主版本号。
发行版可能把补丁回移到较老的内核分支，也可能尚未提供对应更新。自行构建的内核是否包含修复，同样取决于实际源码和补丁集。主线正式发布，也不代表所有发行版已经完成硬件验证或推送更新。
核对时，最直接的线索是提交 0f8b5d90d179b9639be1dbeff59d6d971e6b0527，标题为 PCI: Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe。
如果发行版使用不同的回移提交哈希，可以再按标题及两个设备 ID 查找。不要因为没有搜到同一个哈希，就认定回移不存在。
这项提交是兼容性修复。本文没有依据将它归类为某个新 CVE，也没有把它当成磁盘介质损坏、数据已丢失或所有 VFIO 故障的统一解释。
先做只读核对，不要在生产盘上试复位
受影响场景适合先建立基本记录。下面的命令示例用于 Linux 主机上的只读检查，需要安装相应工具，部分信息可能要求管理员权限。
1 | # 当前运行内核 |
/dev/nvme0 只是示例，必须先确认对应控制器。已经绑定给 vfio-pci 的设备，通常不能再通过宿主机 NVMe 设备节点直接读取这类信息，不能为了查固件就随意解除生产设备绑定。
内核日志也是线索。补丁中的提示为：
1 | Ignoring incorrectly advertised Immediate Readiness support |
不过，没有这条日志不一定表示缺少修复。日志可能已轮转，当前设备也可能没有宣告对应能力；容器或受限环境可能根本看不到完整宿主机日志。设备清单、内核源码或发行版变更记录仍要交叉核对。
共享排障信息前，应去除硬盘序列号、主机标识、业务路径等不必要的信息。本文没有读取当前机器的硬件信息，也没有在任何设备上触发复位。
升级验证要覆盖完整设备生命周期
如果确有直通故障，建议优先使用发行版支持的更新路径，在维护窗口验证。升级前应有备份、可用的旧内核启动项，以及必要的远程控制台或救援方式。对启动盘与生产数据盘，不应直接执行破坏当前访问状态的复位实验。
验证重点也不只是虚拟机能否首次启动。首次交接成功之后，再次启动、重启与重新交接是否稳定，往往更能暴露这种时序问题。测试设备应当可停机、数据已备份，并且不会影响其他运行中的工作负载。
本文建议将以下几项变化分开记录：内核版本与补丁状态、SSD 固件版本、设备绑定方式，以及虚拟机启动和停止流程。如果同时升级内核、固件与虚拟化平台，即使问题消失，也很难确定哪个变化起了作用。
固件升级应遵循厂商工具和适用性说明。上游记录的新固件表现可作为调查线索，不能代替厂商对具体设备、容量和升级路径的确认。
结语
Linux 7.3 中这项小补丁，说明硬件宣告的能力也需要操作系统根据真实行为校正。跳过等待看似只是优化，遇到不守时序的固件，就可能让后面的配置恢复失效。
对使用 NVMe 直通的团队，最有用的下一步是确认设备、固件和实际补丁，而非立即给所有主机换上主线内核。把复位与重新交接纳入测试，才能发现那些在正常读写基准中看不出来的问题。
参考来源
- Linux 7.3 上游版本提交，提交时间为 UTC 2026 年 10 月 18 日 23:14，本文近期选题的版本依据。
- Linux 上游补丁：Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe，问题描述、设备 ID、固件记录和修复实现的主要来源。
- Linux v7.3：drivers/pci/pci.c，核对
pcie_flr()的等待逻辑；drivers/pci/quirks.c，核对设备兼容性处理。 - Phoronix：Linux 7.3 Released 与 Samsung 990 SSD 修复报道，新闻线索与发布背景，技术判断以上游代码为准。
本文根据 2026 年 10 月 19 日查阅资料整理；发行版更新和厂商固件适用性应另行确认。