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

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

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

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

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

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楼：

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

8楼：

回复 #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一个，每个占用一个单独的页框。

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

/*
 * 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;
}

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将无法找到“回家的路”，未执行完的中断处理代码将再也无法获得执行机会。