-
Couldn't load subscription status.
- Fork 590
Description
__next__ at Reddit gave the feedback:
Interrupts can't happen during the lock as the main idea of using
spin_lock_irqis to disable (on the logical core, let's use "local CPU" term for that) interrupts.The whole idea of using
spin_lock_irqsaveinstead of justspin_lock_irqis what is happening during the unlock. At the timespin_lock_irq()is used, interrupts could have been already disabled on the local CPU. And now, when we usespin_unlock_irq()it will re-enable interrupts again for the whole (local) CPU! Yes, it means that our code could have enabled interrupts while someone else (who disabled them before we took the lock) is not expecting that. Example to visualize:
- Interrupts are disabled on a local CPU,
- We use
spin_lock_irq()-> interrupts disabled on a local CPU,- We use
spin_unlock_irq()-> interrupts enabled on a local CPUSo in point 3. all interrupts were enabled (on the local CPU) and the one who disabled them in point 1. is not aware of that fact at all. We enabled the interrupts for him.
_irqsavevariants were introduced to solve this problem.
- Interrupts are disabled on a local CPU,
- We use
spin_lock_irqsave(spinlock_t *lock, unsigned long flags)-> we know that interrupts were disabled at this point as we saved the current state of them in the flags parameter,- We use
spin_unlock_irqrestore-> and at this point, we know based on the flags value, that the interrupts were disabled before_irqsave, so we just go back to the state before invokingspin_lock_irqsaveinstead of always re-enabling interrupts like in the case withspin_unlock_irq().