linux - What happens if a interrupt handler starts spinning?

itemprop="text">

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?

itemprop="text">

class="normal">Answer

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).