LWN：撤回 revocable (可撤销资源管理)

关注了就能看到更多这么棒的文章哦～

Jonathan Corbet
Gemini translation
原文链接：https://lwn.net/Articles/1058041/ 

瞬态设备（transient devices）对操作系统内核构成了特殊的挑战。它们可能随时消失，留下不再指向现有设备但仍可能被未知内核代码使用的内核数据结构。多年来，管理由此产生的生命周期问题一直困扰着内核开发人员。2025 年 9 月，来自 Tzung-Bi Shih 的可撤销资源管理（revocable resource-management）补丁系列似乎为这个问题提供了一个部分的解决方案。然而，自那以后，出现了其他问题，原计划将该系列合并到 7.0 发布版（mainline，主线）的工作已经取消。 

该系列背后的核心思想是仔细管理与瞬态设备相关的数据结构的引用。需要访问这些结构之一的内核代码将尝试获取一个短期的引用；如果设备仍然存在且功能正常，该尝试将成功。该引用受可睡眠的读-复制-更新（sleepable read-copy-update，SRCU）保护，确保相关数据结构在下一个 SRCU 宽限期（grace period）结束前不会消失。 

如果设备从系统中消失，相关驱动程序会将其标记为“已离开（gone）”，并拒绝任何随后对其数据结构引用的请求。在 SRCU 宽限期过后，数据结构的所有者在确信不再存在对其的引用后，可以安全地释放该结构。数据生命周期的不确定性已被一个关于何时不再使用的明确指示所取代。 

Greg Kroah-Hartman 在该系列发布时表示了欢迎（ welcomed ）；他将其纳入了驱动核心仓库（driver-core repository），打算在 7.0 合并窗口（merge window）期间将其推向上游。然而，在 1 月 24 日，Johan Hovold 请求撤回（ requested a revert ），抱怨该系列根本不应该被应用。通常情况下，如果没有实际使用它的代码，这类基础设施是不会被接受的，但这次并未遵循这一惯例；树内并没有可撤销访问功能的用户。Hovold 批评了这一举动，称该功能拟议的使用场景实际上并不需要它，而且代码本身存在一些严重的竞态条件（race-condition）漏洞。他说，可撤销代码应该被撤回，“直到提出并正确评估了重新设计方案”。 

就 Kroah-Hartman 而言，他抵制（ resisted ）撤回这一更改的想法： 

啊，但我确实认为这是前进的方向，因为这种模式/想法在内核的 Rust 侧是行得通的，而且这正是我多年来一直要求的：） 

但是，是的，如果没有真正的用户，我很难证明其合理性。但是，我希望它现在就存在于树中，以便许多其他人可以轻松地尝试它。如果事实证明它不正确且无法正常工作，那么好，我们将彻底删除这些文件。但我还不确定我们是否已经到了那一步。 

他指的是内核中 Rust 代码使用的 Revocable 特性（trait， trait ）。它提供了一个抽象，以（无运行时开销地）访问由其所有者保证不会突然消失的数据结构。对于无法做出这种保证的情况，有一个 try_access() 函数，其工作方式与拟议的 C 功能类似。出于好奇，Danilo Krummrich 详细描述了 Rust 的实现（ described the Rust implementation ）。他指出，由于“语言限制”，C 语言的实现无法以同样的方式工作，但他认为可撤销系列补丁是在探索如何最好地将 Rust 模式应用到 C 侧的一个有价值的尝试。 

然而，Jason Gunthorpe 将这种机制——以及任何允许在设备注销后访问设备的接口——描述为“*危险的*”，并表示使用 try_access() 函数应该被视为“一种代码异味（code smell），表明驱动程序或子系统中存在值得怀疑的地方”。他说，Rust 抽象的真正价值在于它如何强制记录哪些上下文可以安全访问设备结构，而哪些是不确定的。相反，C 版本迫使所有访问都被视为不确定的，失去了文档价值，损害了性能，并可能引发其他类型的错误。 

Hovold 将 Revocable 描述为“一种可能在 Rust 中需要，但在其他地方不一定需要的设计模式”。Gunthorpe 则更强烈地表示（ said more strongly ），添加类似 Rust 抽象的东西“不是我们想要做的”。相反，他认为应该进行更改，以便驱动程序操作（由于它们被聚集在 file_operations 结构体（ structure ）中，通常被称为“fops”）仅在资源不会从它们下方消失的安全上下文中运行。Laurent Pinchart 表示赞同（ agreed ），并勾勒了一个围绕更安全的 file_operations 调用的可能解决方案。 

与此同时，不出所料反对撤回该系列的 Shih 表示（ said ），至少将其保留在 linux-next 中会有所帮助。他发布了另一个系列补丁（ a separate series ），修复了 Hovold 报告的竞态条件。Kroah-Hartman 迅速采纳了这些修复，这引发了 Hovold 的另一次抱怨（ another complaint ），他再次要求撤回该系列。作为回应，Kroah-Hartman 为他接受这些修复辩护（ defended ），但同意在 7.0 发布周期中从构建中禁用可撤销功能。然而，这并没有停止分歧；Hovold 回应说（ responded ）：“API 设计不应该在树内以增量方式进行”。 

又过了几天，在 2 月 6 日，Kroah-Hartman 认输了（ threw in the towel ）并应用了 Hovold 的撤回补丁。“内核开发人员/维护者一年只‘被允许’进行一次重大争论/斗争，我真的不想在今年这么早的时候就耗尽我 2026 年的额度：）”他要求 Shih 仔细研究反馈，并准备一个新的系列补丁进行评审，运气好的话，可能会合并到未来的内核版本中。 

当然，这并不是任何人在为内核（或任何其他自由软件项目）提出改进方案时所希望看到的结果。但这种情况确实时有发生。如果从现在起一切顺利，这次挫折最终将产生一个更好、更具可维护性的解决方案，并最终解决困扰内核开发人员多年的问题。 

LWN 评论概述：

本文引发了关于内核设计哲学与 Rust 抽象模式移植到 C 语言可行性的深入讨论。一些开发者认为这种撤销机制虽然能解决生命周期问题，但引入了不确定性，而另一些人则坚持认为应当通过更严谨的上下文保护来根治资源失效的问题。尽管此次尝试暂告段段落，但社区普遍认为这次辩论有助于达成更清晰的共识。 

  全文完
 LWN 文章遵循 CC BY-SA 4.0 许可协议。 

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～