3

Suppose there is an port-mapped I/O device which arbitrarily generates interrupts on an IRQ line. The device's pending interrupts may be cleared via a single outb call to a particular register.

Furthermore, suppose the follow interrupt handler is assigned to the relevant IRQ line via 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;
}

Is there an inherent race condition in this IRQ handler? For example, if the device generates another interrupt after the "clear IRQ" outb call, but before the handler function returns IRQ_HANDLED, what will happen?

I can think of three scenarios:

  1. IRQ line freezes and can no longer be handled due to deadlock between the device and Linux kernel.
  2. Linux kernel executes handler again immediately after return, in order to handle second interrupt.
  3. Linux kernel interrupts handler with second call to handler.
Vilhelm Gray
  • 11,516
  • 10
  • 61
  • 114

2 Answers2

5

Scenario 2 is the correct one. Interrupts handlers are running with interrupts disabled on the local CPU. So after returning from your handler, the interrupt controller will see that another interrupt occured and your handler will get called again.

What may happen though is that you may miss some interrupts if your are not fast enough and multiple interrupts happen while your are still handling the first one. This should not happen in your case because you have to clear the pending interrupt.

Andy's answer is about another issue. You definitively have to lock access to your device and resources because your handler may run concurrently on different CPUs.

Alexandre Belloni
  • 2,244
  • 13
  • 12
  • Suppose that I return `IRQ_NONE` instead of `IRQ_HANDLED`: would the handler still be called again, or would this case cause a deadlock? – Vilhelm Gray Dec 02 '15 at 19:12
  • 1
    If it is not shared or if it is shared and all the handlers return `IRQ_NONE`, it will be called again but may be disabled for a while by the spurious IRQ handling logic. – Alexandre Belloni Dec 02 '15 at 22:37
1

On SMP systems there is clearly a possibility to have a race. Interrupts are local to the CPU since most of them implementing LAPIC controllers. Thus, you have to protect your data and device access by critical section synchronization algorithm. Due to interrupt context most of suitable here is spin_lock_irqsave().

0andriy
  • 4,183
  • 1
  • 24
  • 37
  • Are you saying that scenario #3 is the outcome: the initial call to the handler is interrupted by a second call to the same handler before the first call returns? – Vilhelm Gray Dec 02 '15 at 15:38
  • [This question](http://stackoverflow.com/questions/2559602/spin-lock-irqsave-vs-spin-lock-irq) about `spin_lock_irq` and `spin_lock_irqsave` helped me to understand this topic. – izzy Dec 02 '15 at 16:12
  • @izzy I'm sorry, I'm not following exactly. I'm concerned about the a deadlock occurring *after* all I/O operations have been performed within the IRQ handler function; therefore I do not believe a spinlock would resolve the issue, since they would span only within the `handler` function. In other words: the `spin_unlock_irq` call would inherently occur before the `return IRQ_HANDLED` line, thus still leaving the race condition possible. – Vilhelm Gray Dec 02 '15 at 16:39