当中断处理程序被另一个中断中断时,中断上下文如何"恢复"？

Question

我读了一些相关的帖子:

(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)哪个上下文是softirq和tasklet？

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.

所以在我的理解中,中断处理程序在中断上下文中运行,并且无法休眠,也就是说,不能像正常进程那样使用支持机制执行上下文切换.

但是中断处理程序可能被另一个中断中断.当第二个中断处理程序完成其工作时,控制流将跳回第一个中断处理程序.

如果没有正常的上下文切换,这种"恢复"是如何实现的？它是否像普通函数调用一样,所有寄存器和其他相关内容都存储在某个堆栈中？

Answer 1

简短的回答是,如果中断处理程序可以被中断中断,则中断处理程序的中断方式与中断中断的任何其他内容完全相同.

假设进程X正在运行.如果进程X被中断,则中断处理程序运行.在某种程度上存在上下文的情况下,它仍然处理X,尽管它现在在内核中运行中断代码(如果你愿意,可以将状态视为X- > interrupt).如果发生另一个中断,则中断被中断,但仍然没有特殊的进程上下文.现在州X- > first_interrupt- > second_interrupt.当第二个中断结束时,第一个中断将恢复,就像第一个中断结束时X将恢复一样.但是,唯一的过程上下文是过程X.

您可以将它们描述为上下文切换,但它们与流程上下文切换不同.它们更类似于进入和退出内核 - 进程上下文保持不变,但执行级别和代码单元可能会发生变化.