为什么嵌套中断中不允许任务切换

zylthinking

understanding the linux kernel 上：

The price to pay for allowing nested kernel control paths is that an interrupt handler must never block, that is, no process switch can take place while an interrupt handler is running. In fact, all the data needed to resume a nested kernel path is stored in the kernel mode stack, which is tightly bound to the current process.

但还是没给出一个有力的理由说明为什么不允许任务切换； 只说了一个返回到被嵌套的内核路径的相关信息都保存在当前任务内核栈上， 因此与当前任务紧密绑定的 经不起推敲的理由。
下文说 Page Fault 可以在内核中发生， 而且 Page Fault 允许任务切换， 因此存在一个内核路径中触发 Page Fault， do_page_fault又引起任务切换的可能； 那么很显然， 返回被 Page Fault 中断的内核路径相关信息应该也报存在当前内核栈中， 那它怎么又允许了？

我觉得所谓不允许任务切换， 根由在于中断的性质本身就是当前任务不相关的， 因此因中断导致任务切换也显得无足够理由， 而且， 任务切换后返回， 说不定就返回用户空间了， 造成一个普通进程抢占中断的结果， 于理不符； 还有就是中断往往是关中断的， 除非任务切换后你接着打开中断， 否则就是返回用户空间后执行然而中断仍然关闭着。

但以上所有， 其实都是实现的考虑而不是什么限制， 从技术上说， 似乎没有理由说嵌套中断就一定不能任务切换
不知理解是否正确

cdtits

貌似中断处理完成后才能进行任务切换等动作吧

onlyxuyang

page fault我记得是不能 嵌套的

cdtits

貌似内核自身是不允许产生 PAGE_FAULT 的吧

linuxfellow

回复 1# zylthinking
中断使用于紧急，高优先级事件的处理。中断资源也是宝贵的， 有限的。如果某个事件处理时能被进程中断，那么这个事件就没有必要用中断，占用一个中断资源。完全可以用软件异步通知方式由进程来实现。
linux的中断处理已经优化了很多，分为前半部， 后半部， work queue来进行多极处理。很紧急的，完全不能耽搁的处理放在前半部；接下来的任务有软中断来完成。软中断不可以被进程或其他软中断抢夺，但是可以被新的中断的前半部抢夺。与中断有关但不重要的处理，就提交到工作队列里去，由内核线程来完成。这一部分就要参与系统进程统一调度。也就是说这一部分可以被进行进程切换。所以你考虑的问题，已经被内核设计人员考虑在内。中断处理中能被进程切换的部分，放入workqueue, 参与进程调度。
中断操作会引起进程切换，但切换不会发生在中断上下文。只是将need_reschedule标志设为1。 cpu从中断上下文返回进程上下文之时，need_reschedule标志会被检查，来决定是否调用schedule()来切换进程。


   

fengguoqing611

从任务切换的流程上来说是不能在中断中切换任务的，因为中断没有TCB。发生任务切换需要将原任务的当前状态包括堆栈、寄存器、进程上下文保存在该任务的TCB中，然后再将新任务的这些信息从TCB导出来加载，建立新任务的运行环境。如果在中断中切换任务，被中断的任务运行环境无法完整保存，下次再运行就会出问题。

wait_rabbit

kernel没有为中断建立专门的数据结构,也因此没有相应的调度措施(类似进程调度).所以中断如果切换出去了,这个中断就丢失了.

如果你有在中断中切换的需求,就必须对kernel进行修改.为中断专门建立数据结构.我记得某一种类unix操作系统就是支持在中断中切换的.