LWN：中断感知自旋锁的新API！

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

A new API for interrupt-aware spinlocks

By Daroc Alden
October 15, 2025
Kangrejos
Gemini flash translation
https://lwn.net/Articles/1039374/

Boqun Feng 在 Kangrejos 2025 会议上讨论了为 Rust 驱动程序添加一个常用 API 的话题，该 API 旨在处理中断，也就是所谓的中断感知的自旋锁（interrupt-aware spinlocks）。大多数驱动程序需要将信息从中断处理程序（interrupt handlers）传递给主驱动代码，而这种数据交换通常通过使用自旋锁来同步。虽然他最初的尝试遇到了问题，但冯伯群最终的解决方案通过跟踪中断禁用嵌套作用域（nested scopes）的数量，也有助于防止 C 代码中的错误。该 补丁集（patch set）包含冯伯群和 Lyude Paul 的工作，目前仍在审核中。

获取自旋锁的代码需要禁用抢占（preemption）：否则，如果它被抢占，其他所有争夺该锁的进程都将白白浪费 CPU 时间。冯伯群表示，同样的情况（几乎）也适用于在中断中使用自旋锁。如果内核代码在进程上下文（process context）中获取了自旋锁，然后一个中断到来，其处理程序试图获取相同的锁，系统就会发生死锁（deadlock）。内核中有一条简单的规则：如果一个锁在中断处理程序和进程上下文两者中都被使用，那么该锁必须是“irq-safe”的（意味着获取者在适当的时候会禁用中断）。内核的 lockdep 工具会检查是否遵循了这条规则。

冯伯群接着说，每个足够复杂的驱动程序都需要一个中断处理程序。为了用 Rust 编写驱动程序，内核程序员将需要一个抽象层来处理中断和 irq-safe 锁。C 语言中现有的 irq-safe 自旋锁使用 `spin_lock_irq()`/`spin_unlock_irq()` 或 `spin_lock_irqsave()`/`spin_lock_irqrestore()`，具体取决于代码是否期望在中断启用（interrupt-enabled）的上下文中运行。前一对函数在释放锁后无条件地启用中断，而后一对函数则保存当前中断状态并在之后恢复。此外，还有一些作用域守卫（scope guards）可以在函数结束时自动解锁这些自旋锁。

Rust API 的首次尝试实际上类似于内核的 作用域守卫。在 Rust 中，拥有一种特殊的守卫类型，在被丢弃（dropped）时释放锁，是一种常见的模式。冯伯群遇到的问题也是 C API 所面临的难题：如果两个锁以错误的顺序被释放会发生什么？考虑一段代码，它在中断启用状态下开始执行，使用 `spin_lock_irqsave()` 获取锁 A（导致中断暂时禁用），然后再次使用 `spin_lock_irqsave()` 获取锁 B。第二次调用将把“禁用”作为当前中断状态存储起来。先释放锁 A 再释放锁 B，最终会导致中断永久禁用，这“不理想”。

冯伯群研究了几种不同的方法来解决这个问题，包括使用令牌类型在编译时跟踪代码是否在可中断上下文（interruptible context）中调用，但这被证明过于复杂。最终，在九月初一次关于这个问题的 邮件列表讨论 中，Thomas Gleixner 评论 道：

更深入地思考。我认为这里存在一个更普遍的问题。

目前 Rust 的大部分工作都在试图模拟 C 语言现有实现的方式。

我认为这从根本上是错误的，因为内核中的许多编程模式在 C 语言中也是根本性的错误。它们仅仅是蔓延开来的技术债（technical debt）。

首先应该做的是从 Rust 的角度来看待它：这些东西应该如何正确实现？

这让冯伯群回到了最初的设计阶段；他最终确定了一种方法，即跟踪中断禁用嵌套作用域的数量。当该数量从零变为一或从一变为零时，代码可以适当地启用或禁用中断，而不再关心锁的释放顺序。这部分代码是用 C 语言编写的，因此也能让内核的其余部分受益。

Andreas Hindborg 询问 `spin_lock_irqsave()` 的所有现有 C 语言用户是否都会适应冯伯群的方法，或者这是否是一个新的 API。冯伯群澄清说，这是一个新的 API，但 Rust 代码应该只使用这一个。他说，在关于这项改变的邮件列表讨论中，调度维护者 Peter Zijlstra 反对 最终出现 三种 锁定和解锁中断感知自旋锁的方式，并且他在尝试机械地转换现有 C 语言用户时遇到了问题，但冯伯群乐观地认为 Zijlstra 会接受更慢的过渡。

Joel Fernandes 询问这个 API 如何与 CondVar::wait() 交互，后者在等待通知时会暂时释放自旋锁（并重新启用中断）。冯伯群说，`CondVar::wait()` 会保存当前中断禁用嵌套的深度，并在之后恢复它。Fernandes 指出这只在持有一个锁的情况下才有效，冯伯群对此表示同意。无论如何，在持有两个锁的情况下等待条件变量（conditional variable）是错误的，“并且 lockdep 会对此发出警告”。

冯伯群提出的方法很好地使 Rust 代码能够与中断感知自旋锁交互，但它还能实现另一个小的 API 更改：Rust 可以拥有一个单独的守卫类型，用于在非自旋锁原因下启用和禁用（per-CPU）中断。如果正在运行的代码已经拥有该类型的一个实例（表明它必须在某个时候禁用了中断），那么它可以在不增加计数的情况下锁定自旋锁。这“在一些不常见的场景中会很有用”，也利于性能优化。

Gary Guo、Benno Lossin 和冯伯群随后展开了一场详细讨论，探讨是否最好让现有中断感知自旋锁守卫（interrupt-aware-spinlock guards）来实现这个目的，而不是创建一个新类型。他们之间的来回讨论很快就超出了我的理解范围，但最终结论是冯伯群的 API 是正确的方向，尽管未来在更多情况下，可能还有一些方法可以避免热路径（hot path）中原子写入（atomic write）的性能开销。

此时，冯伯群深入探讨了新 API 的实现细节。通过 preempt_count() 函数访问一个 32 位的 per-CPU 字段，它比普通的 per-CPU 变量更快；冯伯群尝试看看是否可以“挪用”第 16 到 23 位用于中断禁用嵌套计数，但这会将可跟踪的不可屏蔽中断（non-maskable interrupt, NMI）嵌套级别从 16 位减少到 8 位。冯伯群不确定为什么内核需要 32,000 个 NMI 嵌套级别，但维护者坚持认为需要。由于大多数代码只需要关心是否有任何 NMI 嵌套发生，而不是精确的级别，冯伯群和 Fernandes 最终将 `preempt_count()` 中的 NMI 嵌套计数减少到一位，并使用一个普通的 per-CPU 变量来存储实际深度。

在许多情况下，中断感知自旋锁的现有 C 语言用户应该能够直接使用新的 API。只要函数中存在成对的禁用和启用操作，就可以安全地替换为调用新的 `local_interrupt_disable()` 和 `local_interrupt_enable()` 函数。“但存在一些‘创造性的’非成对使用。”

冯伯群编写了一个工具来查找非成对使用，以评估迁移的麻烦程度。在此过程中，他实际上在内核中发现了一个潜在的错误（latent bug），有人在回调（callback）中使用了无条件 API，而本应使用 `local_irq_save()`。然而，他认为 Rust API 不应该因为重写现有代码而被阻碍；这可以在之后逐步完成。“新的 API 更完善；所以也许人们会自愿切换。”

如果 Zijlstra 和其他维护者对这个答案不满意，冯伯群的备用方案是向 Rust 暴露 per-CPU 变量，然后完全用 Rust 编写新 API——这将使新 API 对 C 语言用户不可用。如果大多数现有 C 语言用户可以轻松地迁移到新的、更安全的 API，那么错过改进内核现有 C 代码的机会将是令人遗憾的。时间将证明冯伯群的提议是否会被采纳，但无论如何，Rust 驱动程序的 API 很快就会离其 C 驱动程序对应部分的同等水平更近一步。

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

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

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