Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error

[Muni Sekhar]

On Thu, May 9, 2024 at 11:27 PM Billie Alsup (balsup) <balsup at cisco.com> wrote:
>
> >From: Muni Sekhar <munisekharrms at 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