Side effects on re enabling an IRQ line from within an interrupt handler

Question

What kind of side effects might appear if an IRQ line is incorrectly re-enabled via spin_unlock_irq in a hard interrupt context? In other words, why is the spin_lock_irq()/spin_unlock_irq() pair discouraged there?

Answer 1

Because say, if the interrupts were OFF and then you acquire a spin_lock_irq and then spin_unlock_irq. This spin_unlock_irq will enable the interrupts back again. But you had started with the state of the system where interrupts were OFF and now they are ON. This is undesirable.

So, what you are doing using spin_lock_irqsave is to *save/preserve * the state of IRQ (ON or OFF) and when you do a spin_lock_irqrestore, you return to the IRQ state that was set before you acquired the lock.

From http://www.linuxjournal.com/article/5833:

With a call to spin_unlock_irqrestore(), interrupts are restored to the state when the lock was acquired.

Risk: When the interrupts are supposed to be disabled and you enable it and there is an IRQ handler that was running (with IRQ disabled) could lead to nesting of interrupts and too much of nesting can crash your system (for eg a network IRQ that interrupts thousands of times within a second).

---

From the kernel source:

spin_lock_irq

326 static inline void spin_lock_irq(spinlock_t *lock)
327 {
328         raw_spin_lock_irq(&lock->rlock);
329 }

spin_lock_irqsave

331 #define spin_lock_irqsave(lock, flags)                          \
332 do {                                                            \
333         raw_spin_lock_irqsave(spinlock_check(lock), flags);     \
334 } while (0)

Here you are first checking the state of IRQ and preserving it.

290 static inline raw_spinlock_t *spinlock_check(spinlock_t *lock)
291 {
292         return &lock->rlock;
293 }

And similar source you can find for spin_unlock_irq & spin_unlock_irqrestore