>From: Muni Sekhar <munisekharrms@xxxxxxxxx> >In the scenario where an interrupt occurs while we are servicing the >interrupt, and in the scenario where it doesn't occur while we are >servicing the interrupt, when should we use the >spin_lock_irqsave/spin_unlock_irqrestore APIs? In my experience, the interrupts are masked by the infrastructure before invoking the interrupt service routine. So unless you explicitly re-enable them, there shouldn't be a nested interrupt for the same interrupt number. It is the code run at process context that must be protected using the irqsave/irqrestore versions. You want to not only enter the critical section, but also prevent the interrupt from occurring (on the same cpu at least). If you enter the critical section in process context, but then take an interrupt and attempt to again enter the critical section, then your interrupt routine will deadlock. the interrupt routine will never be able to acquire the lock, and the process context code that was interrupted will never be able to complete to release the lock. So the process context code requires the irqsave/irqrestore variant to not only take the lock, but also prevent a competing interrupt routine from being triggered while you hold the lock. Bottom line is that if a critical section can be entered via both process context and interrupt context, then the process context invocation should use the irqsave/irqrestore variants to disable the interrupt before taking the lock. If it is common code shared between process context and interrupt context, then there is no harm in calling the irqsave/irqrestore version from both contexts. Otherwise, the standard spin_lock/spin_unlock variants (without irqsave/irqrestore) would be used for a critical section shared by multiple threads (different cpus), or when your code has already (separately) handled disabling interrupts as needed before invoking spin_lock. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
