Linux内核模块mutex临界区调用wait_event_interruptible及上下文相关问题

上下文定义及中断上下文触发场景 #

基础定义 #

• 进程上下文：内核代表用户进程执行（系统调用、进程触发的异常处理）、或是内核线程自身运行时的执行环境。此时current宏指向对应进程的task_struct结构体，可以访问进程地址空间，允许执行阻塞类操作。
• 中断上下文：内核响应异步中断事件时进入的执行环境，和当前被中断的进程无直接关联，不能访问进程用户地址空间，禁止执行任何阻塞操作，因为没有对应的可调度上下文供挂起恢复。

内核模块进入中断上下文的常见场景 #

• 通过request_irq注册的硬件中断处理函数执行时
• 软中断（比如网络收发包软中断、块设备IO软中断）的处理回调执行时
• tasklet处理函数执行时
• 高优先级的下半部处理逻辑中，注意：工作队列的处理回调是运行在进程上下文的，允许阻塞，不属于中断上下文范畴。

mutex临界区调用wait_event_interruptible的安全性 #

结论：这是不符合内核规范的危险用法，完全不推荐使用。
原因如下：

1. wait_event_interruptible会主动触发调度，将当前进程挂起直到条件满足，而你持有的mutex不会被自动释放。此时所有尝试获取该mutex的执行流都会进入阻塞，最长阻塞时间取决于你持锁挂起的时长，严重影响系统并行性。
2. 极易触发死锁：如果负责唤醒等待队列的逻辑本身也需要获取同一个mutex，就会形成「持锁等待唤醒 -> 唤醒逻辑拿不到锁无法唤醒」的死锁闭环。
3. 开启了DEBUG_MUTEX调试选项的内核会直接对该操作抛出告警，明确这是违规用法。

正确实现示例 #

如果需要在等待事件的逻辑中做互斥，需要在进入阻塞前主动释放mutex，唤醒后重新拿锁：

int ret = 0;
mutex_lock(&dev->lock);
while (dev->msg_queue_empty) {
    mutex_unlock(&dev->lock);
    // 等待队列条件满足或收到信号
    ret = wait_event_interruptible(dev->recv_wq, !dev->msg_queue_empty);
    if (ret) {
        // 收到信号，返回可重启系统调用错误码
        return ret;
    }
    mutex_lock(&dev->lock);
}
// 拿到锁且条件满足，处理消息队列逻辑
mutex_unlock(&dev->lock);

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