Question

I am following the Linux Device Drivers. When it introduces spinlocks, it gives the following example:

Your driver is executing and has just taken out a lock that controls access to its device. While the lock is held, the device issues an interrupt, which causes your interrupt handler to run. The interrupt handler, before accessing the device, must also obtain the lock. Taking out a spinlock in an interrupt handler is a legitimate thing to do; that is one of the reasons that spinlock operations do not sleep. But what happens if the interrupt routine executes in the same processor as the code that took out the lock originally? While the interrupt handler is spinning, the noninterrupt code will not be able to run to release the lock. That processor will spin forever.

I don’t understand why if the interrupt handler is spinning, the noninterrupt code cannot be executed.

Is it because the routine in the interrupt handler cannot be preempted? If so, is that to say the interrupt routine must be atomic?

Answer 1

Is it because the routine in the interrupt handler cannot be preempted?

Not by process-context code.

If so, is that to say the interrupt routine must be atomic?

It could be interrupted by a higher priority interrupt or a NMI (or by SMM).