On Thu, May 9, 2024 at 11:27 PM Billie Alsup (balsup) <balsup@xxxxxxxxx> wrote: > > >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. Thanks a lot for the detailed clarification. > > 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. > > -- Thanks, Sekhar _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
