为什么Linux不能在中断中睡眠

中断分析

首先来看中断的流程：

1.进入中断处理程序--->  2.保存关键上下文----> 3.开中断（sti指令）--->

/*

	硬中断：对应于1、2、3步骤。

	在这几个步骤中，所有中断是被屏蔽的，如果在这个时候睡眠了，操作系统不会收到任何中断（包括时钟中断），系统就基本处于瘫痪状态（例如调度器依赖的时钟节拍没有等等……）

	中断handler会使用被中断的进程内核堆栈（但不会对它有任何影响，因为handler使用完后会完全清除它使用的那部分堆栈，恢复被中断前的原貌）。

*/

4.进入中断处理程序的 handler--->5.关中断（cli指令）----> 6.写EOI寄存器（表示中断处理完成）----> 7.开中断。

/* 软中断： 对应上的4（当然，准确的说应该是4步骤的后面一点）。这个时候不能睡眠的关键是因为上下文：

    大家知道操作系统以进程调度为单位，进程的运行在进程的上下文中，以进程描述符作为管理的数据结构。进程可以睡眠的原因是操作系统可以切换不同进程的上下文，进行调度操作，这些操作都以进程描述符为支持。

 中断运行在中断上下文，没有一个所谓的中断描述符来描述它，它不是操作系统调度的单位。一旦在中断上下文中睡眠，首先无法切换上下文（因为没有中断描述符，当前上下文的状态得不到保存），其次，没有人来唤醒它，因为它不是操作系统的调度单位。

 此外，中断的发生是非常非常频繁的，在一个中断睡眠期间，其它中断发生并睡眠了，那很容易就造成中断栈溢出导致系统崩溃。

 */

如果条件满足了（即：有中断描述符，并成为调度器的调度单位，栈也不溢出了，理论上是可以做到中断睡眠的），中断是可以睡眠的，但会引起很多问题.

例如，你在时钟中断中睡眠了，那操作系统的时钟就乱了，调度器也了失去依据；例如，你在一个IPI（处理器间中断）中，其它CPU都在死循环等你答复，你却睡眠了，那其它处理器也不工作了；

例如，你在一个DMA中断中睡眠了，上面的进程还在同步的等待I/O的完成，性能就大大降低了……还可以举出很多例子。

所以，中断是一种紧急事务，需要操作系统立即处理，不是不能做到睡眠，是它没有理由睡眠。

原因

会导致无法唤醒：

中断处理的时候,不应该发生进程切换，因为在中断context中，唯一能打断当前中断handler的只有更高优先级的中断，它不会被进程打断，如果在中断context中休眠，则没有办法唤醒它，因为所有的wake_up_xxx都是针对某个进程而言的，而在中断context中，没有进程的概念，没有一个task_struct（这点对于softirq和tasklet一样），因此真的休眠了，比如调用了会导致block的例程，内核几乎肯定会死。

会导致上下文错乱：

睡眠函数会调用schedule()，切换进程时，保存当前的进程上下文（CPU寄存器的值、进程的状态以及堆栈中的内容），以便以后恢复此进程运行。中断发生后，内核会先保存当前被中断的进程上下文（在调用中断处理程序后恢复）；但在中断处理程序里，CPU寄存器的值肯定已经变化了吧（最重要的程序计数器PC、堆栈SP等），如果此时因为睡眠或阻塞操作调用了schedule()，则保存的进程上下文就不是当前的进程context了，所以不可以在中断处理程序中调用schedule()。

结论

任何os，不管是分时os，还是实时os，不管是什么内核（微内核，或者巨内核），在ISR中都不能进行进程切换。

因为ISR不属于任何进程，而切换只能发生在进程上下文中。虽然ISR在执行过程中要使用进程的系统堆栈，但那只是借用，堆栈并不属于isr，而是属于进程。

也可以从优先级角度来理解。任何进程，不论其优先级多高，也不能高过isr，所以不能剥夺isr对cpu的占有权去运行进程。

Linux是以进程为调度单位的，调度器只看到进程内核栈，而看不到中断栈。在独立中断栈的模式下，如果linux内核在中断路径内发生了调度（从技术上讲，睡眠和调度是一个意思），那么linux将无法找到“回家的路”，未执行完的中断处理代码将再也无法获得执行机会，因为没有人能够唤醒它。

附录：能不能把中断设计为允许睡眠

当一个进程A因为中断被打断时，中断处理程序会使用A的内核栈来保存上下文，因为是“抢”的 A 的CPU，而且用了 A 的内核栈，因此中断应该尽可能快的结束。如果 do_IRQ 时又被时钟中断打断，则继续在 A 的内核栈上保存中断上下文，如果发生调度，则 schedule 进 switch_to，又会在 A 的 task_struct->thread_struct 里保存此时时种中断的上下文。

假如其是在睡眠时被时钟中断打断，并 schedule 的话，假如选中了进程 A，并 switch_to 过去，时钟中断返回后则又是位于原中断睡眠时的状态，抛开其扰乱了与其无关的进程A的运行不说，这里的问题就是：该如何唤醒之呢？？

另外，和该中断共享中断号的中断也会受到影响。

中断不能睡眠的的最大好处就是可以简化内核的设计。如果说中断随时可以睡眠的话, 那么就必须考虑很多其它方面的事情：

比如睡眠之后又出现了同一IRQ号的中断又该怎么办, 等等

其实, 如果自己能把握好，中断中睡眠也是可以的。但是必须能够保证这段代码具有足够的安全性与可靠性（不破坏调度上下文，能够被唤醒）。

ref：