Received-SPF: pass (google.com: domain of linux-kernel+bounces-175387-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <SN7PR11MB660461A6E5F3FB4546B5BDB9D9E62@SN7PR11MB6604.namprd11.prod.outlook.com>
 <CAHhAz+hvb+8sT3BYS_pT3Lmi5X4PjYWRJR=hvmX1e4Ays512FA@mail.gmail.com> <SJ0PR11MB662433ACA8369FDCADC085A2D9E62@SJ0PR11MB6624.namprd11.prod.outlook.com>
In-Reply-To: <SJ0PR11MB662433ACA8369FDCADC085A2D9E62@SJ0PR11MB6624.namprd11.prod.outlook.com>
From: Muni Sekhar <munisekharrms@gmail.com>
Date: Fri, 10 May 2024 12:42:45 +0530
Message-ID: <CAHhAz+gsOpaGPOMLLeGUrDjvUPSp=ZwxgQvOzvjk+zj4=gwo=w@mail.gmail.com>
Subject: Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
To: "Billie Alsup (balsup)" <balsup@cisco.com>, kernelnewbies <kernelnewbies@kernelnewbies.org>, 
	LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 9, 2024 at 11:27=E2=80=AFPM Billie Alsup (balsup) <balsup@cisco=
com> wrote:
>
> >From: Muni Sekhar <munisekharrms@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, ther=
e 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 ir=
qsave/irqrestore
> versions.  You want to not only enter the critical section, but also prev=
ent
> the interrupt from occurring (on the same cpu at least).  If you enter th=
e critical section in
> process context, but then take an interrupt and attempt to again enter th=
e
> critical section, then your interrupt routine will deadlock. the interrup=
t routine will never
> be able to acquire the lock, and the process context code that was interr=
upted will never be
> able to complete to release the lock.  So the process context code requir=
es 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 commo=
n code shared between
> process context and interrupt context, then there is no harm in calling t=
he irqsave/irqrestore
> version from both contexts.
Thanks a lot for the detailed clarification.
>
> Otherwise, the standard spin_lock/spin_unlock variants (without irqsave/i=
rqrestore) 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 invoki=
ng spin_lock.
>
>


--=20
Thanks,
Sekhar