我读了一些相关的帖子：
（1）来自Robert Love：http://permalink.gmane.org/gmane.linux.kernel.kernelnewbies/1791
You cannot sleep in an interrupt handler because interrupts do not have a backing
process context, and thus there is nothing to reschedule back into. In other
words, interrupt handlers are not associated with a task, so there is nothing to
"put to sleep" and (more importantly) "nothing to wake up". They must run
atomically.
（2）来自Which context are softirq and tasklet in?
If sleep is allowed, then the linux cannot schedule them and finally cause a
kernel panic with a dequeue_task error. The interrupt context does not even
have a data structure describing the register info, so they can never be scheduled
by linux. If it is designed to have that structure and can be scheduled, the
performance for interrupt handling process will be effected.
所以在我的理解中，中断处理程序在中断上下文中运行，并且无法休眠，也就是说，不能像正常进程那样使用支持机制执行上下文切换。
但是中断处理程序可能被另一个中断中断。当第二个中断处理程序完成其工作时，控制流将跳回第一个中断处理程序。
如果没有正常的上下文切换，这个“恢复”是如何实现的？它是否像普通函数调用一样，所有寄存器和其他相关内容都存储在某个堆栈中？
答案 0 :(得分：7)
简短的回答是，中断处理程序（如果它可以被中断中断）被中断的方式与中断中断其他任何内容完全相同。
假设进程X正在运行。如果进程X被中断，则中断处理程序运行。在某种程度上存在上下文的情况下，它仍然处理X，尽管它现在在内核中运行中断代码（如果您愿意，可以将状态视为X - ＆gt; interrupt）。如果发生另一个中断，则中断被中断，但仍然没有特殊的进程上下文。现在状态为X - ＆gt; first_interrupt - ＆gt; second_interrupt。当第二个中断结束时，第一个中断将恢复，就像第一个中断结束时X将恢复一样。但是，唯一的流程上下文是流程X.
您可以将这些描述为上下文切换，但它们与流程上下文切换不同。它们更像是进入和退出内核 - 进程上下文保持不变，但执行级别和代码单元可能会发生变化。
答案 1 :(得分：1)
中断例程将在进入实际中断处理程序之前存储一些CPU状态和寄存器，并在返回到中断任务之前恢复这些信息。通常，这种存储和恢复不称为上下文切换，因为中断过程的上下文不会改变。