On Thu, May 9, 2024 at 11:27 PM Billie Alsup (balsup) <bal...@cisco.com> wrote: > > >From: Muni Sekhar <munisekhar...@gmail.com> > >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@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
