再思linux内核在中断路径内不能睡眠/调度的原因（2010）【转】

转自：http://blog.csdn.net/maray/article/details/5770889

Linux内核中断路径中不能睡眠，为什么？

这里就行了很深入的讨论，值得一看：http://bbs2.chinaunix.net/viewthread.php?tid=1618430

但是，他们的讨论最后没有得出一个明确的结论。其中，cskyrain在8楼 的思考触及到了一个要点，但是没有深入展开：

[c-sharp] view plain copy

1楼发表于 2009-11-24 20:36 | 只看该作者
一直认为中断处理函数不能休眠的是天经地义的，可从没认真思考过问什么不能休眠，阻塞。最近看了一下ulk中对这个的解释，感觉还是有点不太明白，
“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 until an interrupt handler is running. In fact, all the data needed to resume a nested kernel control path is stored in the Kernel Mode stack, which is tightly bound to the current process.”
上面把中断处理程序不能休眠归结为中断处理程序可以嵌套，而恢复嵌套的中断处理程序的相关数据放在内核态堆栈中，这个栈和当前进程相关联，这里有一点不明白，既然有栈存储数据，而且进程切换出去后，这个栈也不会被销毁，等进程在切回来时，不同样可以是嵌套的中断处理程序返回吗？（这里先不考了中断处理时间的太长，影响对中断处理的服务问题，只说明中断是否可休眠）。同时我google一下，看到有人对中断不能休眠的以一种解释：
”
中断处理程序用到的所有数据有保存在当前进程的内核堆栈中（一般情况下），如果此时发生了
进程切换，中断处理程序将被阻塞，当在一次发生进程切换时，不一定马上就换回来。比如当
发生一个键盘中断时，键盘处理程序正在进行，此时又恰好发生了进程抢占，切换到了另一个进程
中，假如那个进程不会引起内核的稳定，那么中断处理程序将一直阻塞，内禾根本就没法响应那个中断，
直到在一次发生进程切换。假设最后又切换回执行中断处理程序的那个进程中时，如果它的内核堆栈
受到了无意的破坏怎么办呢？那中断处理程序可能无法在继续运行下去了，此次中断服务失败。而且
现在的处理程序都允许中断嵌套，一个中断被阻塞，其它的都将被阻塞。所以面对错综复杂的内核逻辑，
最好的办法就是在中断处理程序中禁止发生进程切换，这样既提高了中断处理程序的响应速度，也增加了
内核的稳定性与安全性。
“
我感觉他的理由有两个：一个事效率，可能影响处理速度，另一就是：如果它的内核堆栈
受到了无意的破坏怎么办？
对于第一种理由先不讨论，
可第二种，理由我感觉很牵强，如果栈那么容易破坏，哪我也可以说描述进程的数据结构什么的也可能被破坏，哪岂不是进程调度都是不安全的了，
这样按他的说法，就只有第一个效率的原因了。
回到ulk的解释，不知道是不是我理解的有问题，The price to pay for allowing nested kernel control paths is that an interrupt handler must never block
感觉他把中端不能休眠的原因都归结为可支持中断处理程序的嵌套上了。那是不是可以这样理解，如果不支持中断嵌套，中断处理程序就可以休眠了，呵呵呵，貌似这样也不对吧，
问题：中断处理程序不能休眠的原因究竟是什么呢？

7楼：

[c-sharp] view plain copy

kouu 发表于 2009-11-25 11:52
回复 #6 cskyrain 的帖子
中断不能block，应该特指异步中断吧。
看了LZ这两天的帖子，我觉得还是类似4楼的说法比较靠谱：异步中断是独立的上下文，与当前进程无关，所以不能因为中断上下文的block而将无辜的进程给block了。可能就是基于这一初衷吧~ 那些已经将中断处理程序线程化了的实时linux应该是允许中断block的。
而同步的中断（比如系统调用、缺页异常）是代表当前进程的，本来就是可以block的。

8楼：

[c-sharp] view plain copy

回复 #7 kouu 的帖子
呵呵，又翻了翻书，思考了一下，由于时间问题，没心情再从头读ulk，只是跳着查了一下，难免会漏下很多东西，不过还是说说我的理解：
这里中断只代表异步中断，异常代表同步中断，这样系统调用是异常处理，不是中断处理。
这里异常处理是可以休眠block的，因为异常处理所需的数据是存储在异常栈中，而每个进程都有一个异常栈，所以异常处理和进程是相关联的，这样异常处理可以block，被调度出去。
而对于中断，分为两种情况，一种是中断使用单独的中断栈而不使用进程的内核栈的情况，这样，由于所有中断共享一个中断栈，这个中断栈不和特定进程关联，所以，这种中断时不能block的，block后他是不能再被调度。
第二种情况是，中断不使用单独的中断栈，而是使用当前进程的内核栈，这种情况我认为是和异常处理时一样的，这种中断时可以block的，之所以不准许中断 block不是技术上切换不回来，而是逻辑上为了提高处理的效率强制其不能block。
以上是我现阶段的理解，感觉，前俩个的解释应该没什么问题，但最后对不是用中断栈的中断的解释可能有错误的认识，不知kouu对这种解释有何看法？

总体上，大家得到的初步结论是：内核在中断路径内不能睡眠，不是技术上做不到，而是没有理由这么做，或者说在中断路径上睡眠不合理。一方面，外部事件导致当前进程时间片被剥夺，不合理；一方面，中断服务程序应该尽快处理完中断，保证IO吞吐率。

-------------------------------分割线----------------------------

通过阅读ULK中文版第三版164页的内容，让我对这个问题有了一个较为清晰的认识：

内核在编译的时候设置了THREAD_SIZE的值为8K的话, 那么每个进程的内核栈的大小就为8K, 此时如果发生中断时, 那么进程的寄存器等值就会保存到它的8K的内核栈中. 但是如果设置了THREAD_SIZE的大小为4K的话, 内核就会使用3种类型的内核栈, 异常栈, 硬件中断请求栈以及软中断请求栈（ When using 4K stacks, interrupts get their own stack instead of using the currently active kernel stack.）

* 异常栈：每个进程一个。

* 硬中断请求栈：每个CPU一个，每个占用一个单独的页框。do_IRQ()函数内部通过调用execute_on_irq_stack负责切换到该栈中来。

* 软中断请求栈：每个CPU一个，每个占用一个单独的页框。

关于切换到中断栈的方法，请看下面的代码：

[cpp] view plain copy

/*
* do_IRQ handles all normal device IRQ's (the special
* SMP cross-CPU interrupts have their own specific
* handlers).
*/
unsigned int do_IRQ(struct pt_regs *regs)
{
struct pt_regs *old_regs;
/* high bit used in ret_from_ code */
int overflow;
unsigned vector = ~regs->orig_ax;
struct irq_desc *desc;
unsigned irq;
old_regs = set_irq_regs(regs);
irq_enter();
irq = __get_cpu_var(vector_irq)[vector];
overflow = check_stack_overflow();
desc = irq_to_desc(irq);
if (unlikely(!desc)) {
printk(KERN_EMERG "%s: cannot handle IRQ %d vector %#x cpu %d/n",
__func__, irq, vector, smp_processor_id());
BUG();
}
if (!execute_on_irq_stack(overflow, desc, irq)) {
if (unlikely(overflow))
print_stack_overflow();
desc->handle_irq(irq, desc);
}
irq_exit();
set_irq_regs(old_regs);
return 1;
}

[cpp] view plain copy

static inline int
execute_on_irq_stack(int overflow, struct irq_desc *desc, int irq)
{
union irq_ctx *curctx, *irqctx;
u32 *isp, arg1, arg2;
curctx = (union irq_ctx *) current_thread_info();
irqctx = hardirq_ctx[smp_processor_id()];
/*
* this is where we switch to the IRQ stack. However, if we are
* already using the IRQ stack (because we interrupted a hardirq
* handler) we can't do that and just have to keep using the
* current stack (which is the irq stack already after all)
*/
if (unlikely(curctx == irqctx))
return 0;
/* build the stack frame on the IRQ stack */
isp = (u32 *) ((char*)irqctx + sizeof(*irqctx));
irqctx->tinfo.task = curctx->tinfo.task;
irqctx->tinfo.previous_esp = current_stack_pointer;
/*
* Copy the softirq bits in preempt_count so that the
* softirq checks work in the hardirq context.
*/
irqctx->tinfo.preempt_count =
(irqctx->tinfo.preempt_count & ~SOFTIRQ_MASK) |
(curctx->tinfo.preempt_count & SOFTIRQ_MASK);
if (unlikely(overflow))
call_on_stack(print_stack_overflow, isp);
asm volatile("xchgl %%ebx,%%esp /n"
"call *%%edi /n"
"movl %%ebx,%%esp /n"
: "=a" (arg1), "=d" (arg2), "=b" (isp)
: "0" (irq), "1" (desc), "2" (isp),
"D" (desc->handle_irq)
: "memory", "cc", "ecx");
return 1;
}

最后，思考一下标题中的问题：linux内核在中断路径内不能睡眠/调度的原因

Linux是以进程为调度单位的，调度器只看到进程内核栈，而看不到中断栈。在独立中断栈的模式下，如果linux内核在中断路径内发生了调度（从技术上讲，睡眠和调度是一个意思），那么linux将无法找到“回家的路”，未执行完的中断处理代码将再也无法获得执行机会。

再思linux内核在中断路径内不能睡眠/调度的原因（2010）【转】相关推荐

Linux内核实现中断和中断处理（二）
第一部分移步传送门召唤!!:http://www.cnblogs.com/lenomirei/p/5562086.html 上回说了Linux内核实现中断会把中断分为两部分进行处理,上回讲了上部分,这 ...
第三十四期-ARM Linux内核的中断（4）
作者:罗宇哲,中国科学院软件研究所智能软件研究中心上一期中我们介绍了ARM Linux内核中外设中断处理的部分流程,这一期我们将继续介绍ARM Linux内核的外设中断处理流程中与中断描述符相关的部 ...
linux内核的中断上下文,Linux操作系统中中断上下文中的互斥
UP(单CPU系统)上的中断处理互斥如果一个中断处理程序的代码访问或者更新了由非中断的代码(通常称为基准代码)使用的同一数据结构,那么就会出现竞争条件. 幸运的是,得到允许的以内核态执行的进程会临 ...
linux内核 sin头文件,Linux内核中中断request_irq详解--中断共享问题解决
.函数原型如下: 2.4 内核 int request_irq (unsignedintirq,void (*handler)(int,void*,structpt_regs*),unsignedlo ...
linux内核体系学习路径_Linux内核分析（一）linux体系简介|内核源码简介|内核配置编译安装...
从本篇博文开始我将对linux内核进行学习和分析,整个过程必将十分艰辛,但我会坚持到底,同时在博文中如果那些地方有问题还请各位大神为我讲解. 今天我们会分析到以下内容: 1. Linux体系结构简介 ...
linux内核等价多路径路由,高级路由 - 我是*李世民*的个人空间 - OSCHINA - 中文开源技术交流社区...
策略路由背后的概念 Linux内核在默认情况下使用两张路由表:一张表用于本地路由,另一张可以由管理员来配置.如果内核编译支持策略路由,那么可以有多大255张不同的.相互独立的路由表.策略路由背后的主要 ...
谷歌喊话三星：别再搞 Linux 内核代码了，安卓安全也不保了
聚焦源代码安全,网罗国内外最新资讯! 编译:奇安信代码卫士团队谷歌 Project Zero 团队表示,三星为阻止 Galaxy 手机遭攻击而修改了内核代码,但实际上引发了更多的安全漏洞. 谷歌安全 ...
Linux内核机制总结进程管理之SMP调度(六)
文章目录 1 SMP调度 1.1 进程的cpu亲和性 1.2 对调度器的拓展 1.3 期限调度类的cpu负载均衡 1.4 实时调度类的cpu负载均衡 1.5 公平调度类的cpu负载均衡 1.6 迁移线 ...
海思linux内核太大,一次解决Linux内核内存泄漏实战全过程
责编 | 张红月来源 | Linux阅码场 2020 年转眼间白驹过隙般飞奔而去,在岁末年初的当口,笔者在回顾这一年程序员世界的大事件后,突然发觉如何避免程序员面向监狱编程是个特别值得一谈的话题. ...

再思linux内核在中断路径内不能睡眠/调度的原因（2010）【转】

再思linux内核在中断路径内不能睡眠/调度的原因（2010）【转】相关推荐

最新文章

热门文章