Linux kernel design and implementation (LKD) learning--how to understand that interrupt handlers can use spin locks __linux

How to understand that an interrupt handler can use a spin lock:

My understanding is that the interrupt handler can share a resource with the process being performed by the current processor, while the protection mechanism for the shared resource is a spin lock. The shared resource that will be used by the interrupt handler is protected by a spin lock, with the addition of the condition that the interrupt is first prohibited. This means that when the processor processes the current process, once the data that is shared with the interrupt is invoked, it must first have an interrupt-blocking action and then obtain its lock-right, that is, the process does not exist interrupted interrupts (interrupted), and will not produce a deadlock. The processor can respond to interrupts only after the process has finished processing the shared data to release the lock, which also restores the interrupted action. If there was just this interruption, it would interrupt the process the processor was working on, but it was clear that the process was running out of shared data (releasing the lock), so the interrupt handler could run smoothly with the lock right when it was used in the shared data, until leaving the original location to continue processing the original process.

The main purpose is to understand the role of prohibiting interruptions.