Concurrent interrupt handling for shared IRQ in Linux

Question

What are the things that can be done or needs to be done in the top-half of an ISR handler. I see that the interrupts are disabled first, so when this is done, won't we miss the other interrupts (on the same IRQ line) that might arrive while handling the current interrupt?

Or is there any "entity" that keeps track of the missing interrupts, so that they can be handled after interrupts are enabled back again for that line at the end of the current running ISR?

Answer 1

A quick word on shared interrupts: shared interrupt lines should always use level-sensitive devices which should all be the same level (hi vs. low) as well. With edge-triggered interrupts there would be no way to guarantee that after one device triggers, but before it returns to its steady state, the other device won't trigger. It becomes a race condition that is impossible to avoid.

Level-triggered interrupts on the other hand stay active until a flag on the device that triggered it has been cleared. While handling the first device, if the second device triggers, then it will wait with the IRQ line held active until the handler enables the IRQ line again.

Answer 2

The interrupt handler should be minimal as possible.

It's not always necessary to disable interrupts. Some architectures work with nested interrupts. Anyway, if you disable interrupts, you should do it for a command or two, not more. This will create a delay and possibly miss interrupts.

When I handle interrupts, I usually do two things. One is to clear the flag that caused the interrupt. The second is to trigger some functions afterwards (tasklet, workqueue, etc.)

Be aware not to use any method in an interrupt handler that may sleep, like printf, or acquiring a mutex.

Answer 3

You should properly acknowledge the interrupt to avoid IRQ storms. Process the interrupt itself - if you have a large job to do, offload to the bottom half.

What happens when interrupts are disabled: On x86 the cli instruction disables the interrupts on the current CPU where the ISR is running. ONE IRQ is buffered, so when the interrupts are restored with sti, it is delivered.

When using APIC interrupts, the buffering happens in the kernel itself. The kernel acknowledges the APIC interrupt and triggers it again when enable_irq is called.