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

 http://www.ednchina.com/ART_51707_29_0_OA_021acc67.HTM

 

　这个问题实际上是一个老生常谈的问题，答案也很简单，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中的硬中断管理机制做了一些代码分析，这一块代码量不是很大，可移植性非常的好~~建议大家阅读，对我上述的分析和理解存在什么不同意见，欢迎大家讨论

 

 

为什么在中断上下文中不能休眠?

这个问题有很多人问过,我看了下linux得内核代码,原因如下 当然我不能保证一定对,如果有牛人理解得更好,欢迎指正)
1.中断处理的时候,不应该发生进程切换,因为在中断context中,唯一能打断当前中断handler的只有更高优先级的中断,它不会被进程打断(这点对于softirq,tasklet也一样,因此这些bottom half也不能休眠),如果在中断context中休眠,则没有办法唤醒它,因为所有的wake_up_xxx都是针对某个进程而言的,而在中断context中,没有进程的概念,没有一个task_struct(这点对于softirq和tasklet一样),因此真的休眠了,比如调用了会导致block的例程,内核几乎肯定会死.
2.schedule()在切换进程时，保存当前的进程上下文(CPU寄存器的值、进程的状态以及堆栈中的内容),以便以后恢复此进程运行。中断发生后，内核会先保存当前被中断的进程上下文(在调用中断处理程序后恢复)；
但在中断处理程序里，CPU寄存器的值肯定已经变化了吧(最重要的程序计数器PC、堆栈SP等)，如果此时因为睡眠或阻塞操作调用了schedule()，则保存的进程上下文就不是当前的进程context了.所以不可以在中断处理程序中调用schedule()。
3.2.4内核中schedule()函数本身在进来的时候判断是否处于中断上下文:
if(unlikely(in_interrupt()))
BUG();
因此,强行调用schedule()的结果就是内核BUG,但我看2.6.18的内核schedule()的实现却没有这句,改掉了.
4.中断handler会使用被中断的进程内核堆栈,但不会对它有任何影响,因为handler使用完后会完全清除它使用的那部分堆栈,恢复被中断前的原貌.
5.处于中断context时候,内核是不可抢占的,因此,如果休眠,则内核一定挂起.
---------------------------------------------------------------------------
在windows NT内核中,这个也一样,和linux内核不一样的一个地方是:NT内核发明了irql概念,内核是可抢占的,但在内核中只能是高irql的抢占低IRQL,所有的中断处理程序运行在DIRQL上,而进程调度运行在dispatch level上,这个比DIRQL低,此外相当于linux中的softirq机制的dpc机制实现bottom half的处理,但dpc也是运行在dispatch level上的,因此它和中断handler一样不能被进程调度抢占,这样如果在这些例程中休眠或者调用可能block的函数,则内核一定hang,windows NT在这种情况下会调用KeBugCheckEx()挂起机器,BSOD了.