linux-kernel - Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHhAz+gsOpaGPOMLLeGUrDjvUPSp=ZwxgQvOzvjk+zj4=gwo=w@mail.gmail.com>
Date: Fri, 10 May 2024 12:42:45 +0530
From: Muni Sekhar <munisekharrms@...il.com>
To: "Billie Alsup (balsup)" <balsup@...co.com>, kernelnewbies <kernelnewbies@...nelnewbies.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error

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