为什么中断上下文不可以休眠

最新推荐文章于 2023-08-23 14:37:32 发布

geekster

最新推荐文章于 2023-08-23 14:37:32 发布

阅读量1.4k

点赞数 1

分类专栏： linux kernel

linux kernel 专栏收录该内容

17 篇文章 1 订阅

订阅专栏

不可在中断例程中休眠的原因

如果在某个系统调用中把当前进程休眠，是有明确目标的，这个目标就是过来call这个系统调用的进程（注意这个进程正在running）。

但是中断和进程是异步的，在中断上下文中，当前进程大部分时候和中断代码可能一点关系都没有。要是在这里调用了休眠代码，把当前进程给休眠了，那就极有可能把无关的进程休眠了。再者，如果中断不断到来，会殃及许多无辜的进程。

在中断中休眠某个特定进程是可以实现的，通过内核的task_struct链表可以找到的，不论是根据PID还是name。但是只要这个进程不是当前进程，休眠它也可能没有必要。可能这个进程本来就在休眠；或者正在执行队列中但是还没执行到，如果执行到他了可能又无须休眠了。

还有一个原因是中断也是所谓的原子上下文，有的中断例程中会禁止所有中断，有的中断例程还会使用自旋锁等机制，在其中使用休眠也是非常危险的。下面会介绍。

--------------------------------------------------------------------------------

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

2.schedule()在切换进程时，保存当前的进程上下文(CPU寄存器的值、进程的状态以及堆栈中的内容),以便以后恢复此进程运行。中断发生后，内核会先保存当前被中断的进程上下文(在调用中断处理程序后恢复)；

但在中断处理程序里，CPU寄存器的值肯定已经变化了吧(最重要的程序计数器PC、堆栈SP等)，如果此时因为睡眠或阻塞操作调用了schedule()，则保存的进程上下文就不是当前的进程context了.所以不可以在中断处理程序中调用schedule()。

3.2.4内核中schedule()函数本身在进来的时候判断是否处于中断上下文:
if(unlikely(in_interrupt()))
BUG();

因此,强行调用schedule()的结果就是内核BUG,但我看2.6.18的内核schedule()的实现却没有这句,改掉了.

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

5.处于中断context时候,内核是不可抢占的,因此,如果休眠,则内核一定挂起.

------------------------------------------------------------------------------------------------------------------------------------

先把中断处理流程给出来
1.进入中断处理程序--->2.保存关键上下文---->3.开中断（sti指令）--->4.进入中断处理程序的handler--->5.关中断（cli指令）---->6.写EOI寄存器（表示中断处理完成）---->7.开中断。
复制代码

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

软中断：
对应上图的4（当然，准确的说应该是4步骤的后面一点，先把话说保险点，免得思一克又开始较真）。这个时候不能睡眠的关键是因为上下文。
大家知道操作系统以进程调度为单位，进程的运行在进程的上下文中，以进程描述符作为管理的数据结构。进程可以睡眠的原因是操作系统可以切换不同进程的上下文，进行调度操作，这些操作都以进程描述符为支持。
中断运行在中断上下文，没有一个所谓的中断描述符来描述它，它不是操作系统调度的单位。一旦在中断上下文中睡眠，首先无法切换上下文（因为没有中断描述符，当前上下文的状态得不到保存），其次，没有人来唤醒它，因为它不是操作系统的调度单位。
此外，中断的发生是非常非常频繁的，在一个中断睡眠期间，其它中断发生并睡眠了，那很容易就造成中断栈溢出导致系统崩溃。

如果上述条件满足了（也就是有中断描述符，并成为调度器的调度单位，栈也不溢出了，理论上是可以做到中断睡眠的），中断是可以睡眠的，但会引起很多问题.例如，你在时钟中断中睡眠了，那操作系统的时钟就乱了，调度器也了失去依据；例如，你在一个IPI（处理器间中断）中，其它CPU都在死循环等你答复，你确睡眠了，那其它处理器也不工作了；例如，你在一个DMA中断中睡眠了，上面的进程还在同步的等待I/O的完成，性能就大大降低了……还可以举出很多例子。所以，中断是一种紧急事务，需要操作系统立即处理，不是不能做到睡眠，是它没有理由睡眠。

----------------------------------------------------------

通过int 0x80只是实现系统调用的一种方式，而且是最古老的一种方式。应用程序利用int指令进行主动陷入内核，更应该称之为软件中断，这与前面提到的下半部的软中断不是一个概念。应用程序执行系统调用进入到内核后，内核处于进程上下文，是可以阻塞/睡眠的，是中断上下文不能睡眠。

-----------------------------------------------------------

这个说起来有点多,一一来看:
1,中断要根据前后文来说,一般说中断上下文中不能睡眠,这个中断是指硬件事件发生,触发CPU停止当前活动转而去处理硬件请求.
2,根据硬件请求响应处理逻辑的实时紧要与否,将整个中断处理过程分为上半部和下半部.
3,上半部也就是所谓的硬中断处理逻辑,其要求cpu在收到硬件请求后必须马上处理的事情,比如网卡收到数据包了,把数据包从网卡缓存拷贝到主存(可以由DMA完成,但寄存器的修改以及资源设定还是要由cpu去做)的逻辑就需要cpu立即去做,不做的话,网络新来的数据包就可能丢失.所以这些紧要操作逻辑为硬中断处理.
4,下半部有很多种机制,其中就包括软中断,还有tasklet,workqueue等,软中断只是其中的一种,由于历史的原因,有时候是混淆称呼下半部和软中断的.
5,软中断处理的逻辑并不那么严格要求及时,比如对网络数据包的处理,因为逻辑复杂,不适合放到硬中断里去做,因为要尽量保证硬中断短小精悍.
6,linux调度是以进程(或者说线程)来的,即做调度是不同进程上下文的切换.
7,而可以看到软中断逻辑不属于任何进程,所以才不能睡眠,因为一旦睡眠,cpu切换出去,就切不回来了(和6一起理解).并不是说无法做到在软/硬中断睡眠,只是目前Linux的实现就是这样的,不允许你这么做,要是这么做了,你就等死.

8,系统调用是属于软中断?难道是指int 0x80?这个不知道是什么概念,但肯定不是与上面的软中断同一个意思.给你两个链接:
http://lenky.info/2013/02/04/32% ... %E8%B0%83%E7%94%A8/
http://lenky.info/2013/02/04/64% ... %E8%B0%83%E7%94%A8/