Kernel Newbies archive mirror
 help / color / mirror / Atom feed
From: "Billie Alsup (balsup)" <balsup@cisco.com>
To: Muni Sekhar <munisekharrms@gmail.com>,
	kernelnewbies <kernelnewbies@kernelnewbies.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
Date: Thu, 9 May 2024 15:26:34 +0000	[thread overview]
Message-ID: <SN7PR11MB660461A6E5F3FB4546B5BDB9D9E62@SN7PR11MB6604.namprd11.prod.outlook.com> (raw)

>From: Muni Sekhar <munisekharrms@gmail.com>

>Here is a brief overview of how I have implemented spin locks in my module:
>
>spinlock_t my_spinlock; // Declare a spin lock
>
>// In ISR context (interrupt handler):
>spin_lock_irqsave(&my_spinlock, flags);
>// ... Critical section ...
>spin_unlock_irqrestore(&my_spinlock, flags);
>
>
>// In process context: (struct file_operations.read)
>spin_lock(&my_spinlock);
>// ... Critical section ...
>spin_unlock(&my_spinlock);

from my understanding, you have the usage backwards.  It is the irqsave/irqrestore versions that should be used within process context to prevent the interrupt from being handled on the same cpu while executing in your critical section.

The use of irqsave/irqrestore within the isr itself is ok, although perhaps unnecessary.  It depends on whether the interrupt can occur again while you are servicing the interrupt (whether on this cpu or another).  Usually (?) the same interrupt does not nest, unless you have explicitly coded to allow it (for example, by acknowledging and re-enabling the interrupt early in your ISR). Certainly the spinlock is necessary to protect the critical section from running in an isr on one cpu and process space on another cpu.

From a lockup perspective, not doing the irqsave/irqrestore from process context could explain your problem. Also look for code (anywhere!) that blindly enables interrupts, rather than doing irqrestore from a prior irqsave.

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

             reply	other threads:[~2024-05-09 15:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-09 15:26 Billie Alsup (balsup) [this message]
2024-05-09 17:20 ` Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error Muni Sekhar
2024-05-09 17:57   ` Billie Alsup (balsup)
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=SN7PR11MB660461A6E5F3FB4546B5BDB9D9E62@SN7PR11MB6604.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).