Kernel Newbies archive mirror
 help / color / mirror / Atom feed
From: "Billie Alsup (balsup)" <balsup@cisco.com>
To: Muni Sekhar <munisekharrms@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
Date: Thu, 9 May 2024 17:57:44 +0000	[thread overview]
Message-ID: <SJ0PR11MB662433ACA8369FDCADC085A2D9E62@SJ0PR11MB6624.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAHhAz+hvb+8sT3BYS_pT3Lmi5X4PjYWRJR=hvmX1e4Ays512FA@mail.gmail.com>

>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, 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.

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.



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2024-05-09 17:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-09 15:26 Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error Billie Alsup (balsup)
2024-05-09 17:20 ` Muni Sekhar
2024-05-09 17:57   ` Billie Alsup (balsup) [this message]
2024-05-10  7:12     ` Muni Sekhar
  -- strict thread matches above, loose matches on Subject: below --
2024-05-09 14:39 Muni Sekhar
2024-05-17 20:44 ` jim.cromie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR11MB662433ACA8369FDCADC085A2D9E62@SJ0PR11MB6624.namprd11.prod.outlook.com \
    --to=balsup@cisco.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=munisekharrms@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).