为何wait_for_completion()未使用spin_lock_irqsave()及相关疑问

问题背景 #

在研究Completion API实现细节时发现：若处理器已禁用中断，则无法调用wait_for_completion()，但信号量无此限制。内核文档明确说明：wait_for_completion()内部调用spin_lock_irq()/spin_unlock_irq()，仅能在中断启用时安全调用，否则会导致难以检测的虚假中断启用问题。

1. 为何wait_for_completion()内部不调用irqsave版本的自旋锁？ #

核心原因在于Completion的设计定位和使用场景限制：

• wait_for_completion()是进程上下文专属的可睡眠同步原语，其预期使用场景是中断处于启用状态的环境。在中断禁用的上下文里，调用可睡眠函数本身就是内核编程的禁忌——睡眠会导致调度器切换，而中断禁用时调度器无法正常工作，会引发系统死锁或异常。
• irqsave版本的锁（如spin_lock_irqsave()）的作用是保存当前中断状态，解锁时恢复该状态。但wait_for_completion()会让进程进入睡眠，睡眠过程中内核调度器可能会修改中断状态（比如其他进程运行时可能启用/禁用中断），若此时用irqsave恢复旧状态，会破坏系统中断状态的一致性，引发更隐蔽的问题。
• Completion的设计追求简单高效，仅针对单向事件通知的明确场景，不需要兼容中断禁用的非法使用场景，因此没必要引入irqsave锁的额外开销和复杂度。

2. 这个限制是否会让Completion不如信号量受欢迎？ #

不会，因为两者的定位和适用场景完全不同：

• 信号量是通用同步原语，支持多种场景：比如资源计数、多线程等待、甚至中断上下文的down_trylock()非阻塞操作，灵活性高但语义相对模糊。
• Completion是专门针对单向事件通知的轻量级原语，语义明确：一个线程等待另一个线程完成某个特定动作，完成后发出通知唤醒等待线程。这种场景下，Completion比信号量更高效（没有信号量的计数逻辑开销），代码可读性更强。
• 所谓的“限制”是合理的使用约束：既然wait_for_completion()是可睡眠函数，本来就不应该在中断禁用的上下文调用，这个限制只是明确了它的合法使用范围，而非设计缺陷。开发者会根据具体需求选择：需要单向事件同步时用Completion，需要通用互斥/资源管理时用信号量，两者各司其职，不存在谁替代谁的情况。

内容的提问来源于stack exchange，提问作者MankPan