当中断处理程序被另一个中断打断时，中断上下文是如何“恢复”的？

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)来自哪个上下文中的软中断和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.

据我所知，中断处理程序运行在中断上下文中，并且不能休眠，也就是说，不能像正常进程那样使用后备机制执行上下文切换。

但是，中断处理程序可以被另一个中断打断。当第二个中断处理程序完成工作后，控制流会跳回第一个中断处理程序。

没有正常的上下文切换，如何实现这种“还原”呢？这是不是像普通函数调用一样，所有寄存器和其他相关内容都存储在某个堆栈中？

- feirainy

---

Robert Love: ...因为中断没有_支持进程上下文_，而软中断/任务队列：中断上下文甚至没有描述寄存器信息的数据结构。在这两种情况下，技术上的描述是它们没有thread_info、task_struct或struct mm。你需要一个task_struct来进行调度。中断等可以在thread_info中作为堆栈免费乘车，以堆叠内核上下文。 - artless noise

Answer 1

简单来说，如果中断处理程序可以被中断，则它会被中断，就像其他任何东西一样。假设进程X正在运行，如果进程X被中断，则中断处理程序将运行。在某种程度上，仍然是进程X，尽管现在它在内核中运行中断代码（如果您喜欢，请将状态想象为X->interrupt）。如果发生另一个中断，则中断将被中断，但仍没有特殊的进程上下文。状态现在是X->first_interrupt->second_interrupt。当第二个中断完成时，第一个中断将恢复，就像当第一个中断完成时X将恢复一样。然而，唯一的进程上下文是进程X。您可以将这些描述为上下文切换，但它们不像进程上下文切换。它们更类似于进入和退出内核-进程上下文保持不变，但执行级别和代码单元可以更改。

- David Schwartz

---

当第二个中断打断时，第一个中断处理程序的“上下文”（例如寄存器）被存储在内核栈中，就像进程X被第一个中断打断的方式一样。 - feirainy

@feirainy 没错。是的。中断处理程序劫持（或者如果你愿意的话，就是'借用'）了进程上下文，而不是切换。这使得中断的成本很低。 - David Schwartz

Answer 2

中断例程将在进入真正的中断处理程序之前存储一些CPU状态和寄存器，并在返回到被中断的任务之前恢复这些信息。通常，这种存储和恢复不被称为上下文切换，因为被中断进程的上下文没有改变。

- Chris Tsui

Answer 3

截至2020年，在Linux中，中断（硬IRQ）通常不会在本地CPU上嵌套。这至少由活跃贡献于Linux内核的小组/维护者提到了两次：

来自Jakub Kicinski于2020年撰写的NAPI更新：

“…因为正常的中断在Linux中不会嵌套，所以系统无法在处理一个中断时服务任何新的中断。”

并且来自2022年的Bootlin：

“…在本地CPU上运行中断处理程序时，所有中断都被禁用...”

因此，对于Linux内核而言，这个问题现在可能不太相关。

- 07 0xff