软中断上下文能够睡眠吗？

这个问题实际上是一个老生常谈的问题，答案也很简单， Linux 在软中断上下文中是不能睡眠的，原因在于 Linux 的软中断实现上下文有可能是中断上下文，如果在中断上下文中睡眠，那么会导致 Linux 无法调度，直接的反应是系统 Kernel Panic ，并且提示 dequeue_task 出错。所以，在软中断上下文中，我们不能使用信号量等可能导致睡眠的函数，这一点在编写 IO 回调函数时需要特别注意。在最近的一个项目中，我们在 dm-io 的 callback 函数中去持有 semaphore 访问竞争资源，导致了系统的 kernel panic 。其原因就在于 dm-io 的回调函数在 scsi soft irq 中执行， scsi soft irq 是一个软中断，其会在硬中断发生之后被执行，执行上下文为中断上下文。

 

       中断上下文中无法睡眠的原因大家一定很清楚，原因在于中断上下文不是一个进程上下文，其没有一个专门用来描述 CPU 寄 存器等信息的数据结构，所以无法被调度器调度。如果将中断上下文也设计成进程上下文，那么调度器就可以对其进行调度，如果在开中断的情况下，其自然就可以 睡眠了。但是，如果这样设计，那么中断处理的效率将会降低。中断（硬中断、软中断）处理都是些耗时不是很长，对实时性要求很高，执行频度较高的应用，所 以，如果采用一个专门的后台 daemon 对其处理，显然并不合适。

 

       Linux 对中断进行了有效的管理，一个中断发生之后，都会通过相应的中断向量表获取该中断的处理函数。在 Linux 操作系统中都会调用 do_IRQ 这个函数，在这个函数中都会执行 __do_IRQ （）， __do_IRQ 函数调用该中断的具体执行函数。在执行过程中，该函数通过中断号找到具体的中断描述结构 irq_desc ，该结构对某一具体硬件中断进行了描述。在 irq_desc 结构中存在一条链表 irqaction ，这条链表中的某一项成员都是一个中断处理方法。这条链表很有意思，其实现了中断共享，例如传统的 PCI 总线就是采用共享中断的方法，该链表中的一个节点就对应了一个 PCI 设备的中断处理方法。在 PCI 设备驱动加载时，都需要注册本设备的中断处理函数，通常会调用 request_irq 这个函数，通过这个函数会构造一个具体的 irq action ，然后挂接到某个具体 irq_desc 的 action 链表下，实现中断处理方法的注册。在 __do_IRQ 函数中会通过 handle_IRQ_event （）函数遍历所有的 action 节点，完成中断处理过程。到目前为止，中断处理函数 do_IRQ 完 成的都是上半部的工作，也就是设备注册的中断服务程序。在中断上半部中，通常都是关中断的，基本都是完成很简单的操作，否则将会导致中断的丢失。耗时时间 相对较长，对实时性要求不是最高的应用都会被延迟处理，都会在中断下半部中执行。所以，在中断上半部中都会触发软中断事件，然后执行完毕，退出服务。

 

       __do_IRQ 完成之后，返回到 do_IRQ 函数，在该函数中调用了一个非常重要的函数 irq_exit （），在该函数中调用 invoke_softirq （）， invoke_softirq 调用 do_softirq （）函数，执行软中断的操作。此时，程序的执行环境还是中断上下文，但是与中断上半部不同的是，软中断执行过程中是开中断的，能够被硬中断而中断。所以，如果用户的程序在软中断中睡眠，操作系统该如何调度呢？只有 kernel panic 了。另外，软中断除了上述执行点之外，还有其他的执行点，在内核中还有一个软中断的 daemon 处理软中断事务，驱动程序也可以自己触发一个软中断事件，并且在软中断的 daemon 上下文中执行。但是硬中断触发的事件都不会在这个 daemon 的上下文中执行，除非修改 Linux 中的 do__IRQ 代码。

 

       上述对软中断的执行做了简要分析，我对 Linux 中的硬中断管理机制做了一些代码分析，这一块代码量不是很大，可移植性非常的好 ~~ 建议大家阅读，对我上述的分析和理解存在什么不同意见，欢迎大家讨论。

 

本文转载自：http://blog.ednchina.com/tiloog/182873/message.aspx