相关疑难解决方法(0)

为什么在中断上下文中执行的内核代码/线程无法休眠?

我正在阅读Robert Love的以下文章

http://www.linuxjournal.com/article/6916

说的是

"...让我们讨论工作队列在进程上下文中运行的事实.这与其他下半部机制形成对比,后者都在中断上下文中运行.在中断上下文中运行的代码无法休眠或阻塞,因为中断上下文没有重新安排的后台进程.因此,由于中断处理程序与进程没有关联,调度程序没有任何东西可以进入休眠状态,更重要的是,调度程序无需唤醒..."

我不明白.AFAIK,内核中的调度程序是O(1),它是通过位图实现的.那么什么阻止了scehduler将中断上下文置于睡眠状态并采取下一个可调度进程并将其传递给控件?

linux-kernel

48
推荐指数
3
解决办法
3万
查看次数

Linux IRQ处理程序中的固有竞争条件

假设有一个端口映射的I/O设备,它可以在IRQ线上任意产生中断.可以通过outb对特定寄存器的单次调用来清除设备的待处理中断.

此外,假设通过以下方式将跟随中断处理程序分配给相关的IRQ线request_irq:

irqreturn_t handler(int irq, void *data)
{
        /* clear pending IRQ on device */
        outb(0, CLEAR_IRQ_REGISTER_ADDR);

        /* device may generate another IRQ at this point,
         * but this handler function has not yet returned */

        /* signal kernel that IRQ has been handled */
        return IRQ_HANDLED;
}
Run Code Online (Sandbox Code Playgroud)

这个IRQ处理程序中是否存在固有的竞争条件?例如,如果设备在"清除IRQ" outb调用之后但在handler函数返回之前生成另一个中断IRQ_HANDLED,会发生什么?

我可以想到三种情况:

  1. 由于设备和Linux内核之间的死锁,IRQ线冻结并且无法再处理.
  2. handler返回后,Linux内核立即再次执行,以便处理第二个中断.
  3. Linux内核中断handler第二次调用handler.

linux interrupt race-condition linux-kernel interrupt-handling

3
推荐指数
1
解决办法
452
查看次数