Kernel Newbies archive mirror
 help / color / mirror / Atom feed
From: Muni Sekhar <munisekharrms@gmail.com>
To: kernelnewbies <kernelnewbies@kernelnewbies.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
Date: Thu, 9 May 2024 20:09:13 +0530	[thread overview]
Message-ID: <CAHhAz+isxCcxq3QLqmapcQwvZDYb-PL7FAi2cFMgFwXVNU2h7g@mail.gmail.com> (raw)

Dear Linux Kernel Community,

I am reaching out to seek assistance regarding the usage of spin locks
in the Linux kernel and to address a recurring issue related to hard
LOCKUP errors that I have encountered during testing.

Recently, I developed a small kernel module that involves ISR handling
and utilizes the spinlock_t primitive. In my module, I have employed
spin locks both in process context using spin_lock() and spin_unlock()
APIs, as well as in ISR context using spin_lock_irqsave() and
spin_unlock_irqrestore() APIs.

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);


However, during testing, I have encountered a scenario where a hard
LOCKUP (NMI watchdog: Watchdog detected hard LOCKUP on cpu 2) error
occurs, specifically when a process context code execution triggers
the spin_lock() function and is preempted by an interrupt that enters
the ISR context and encounters the spin_lock_irqsave() function. This
situation leads to the CPU being stuck indefinitely.

My primary concern is to understand the appropriate usage of spin
locks in both process and ISR contexts to avoid such hard LOCKUP
errors. I am seeking clarification on the following points:

    Is it safe to use spin_lock_irqsave() and spin_unlock_irqrestore()
APIs in ISR context and spin_lock() and spin_unlock() APIs in process
context simultaneously?
    In scenarios where a process context code execution is preempted
by an interrupt and enters ISR context, how should spin locks be used
to prevent hard LOCKUP errors?
    Are there any specific guidelines or best practices for using spin
locks in scenarios involving both process and ISR contexts?

I would greatly appreciate any insights, guidance, or suggestions from
the experienced members of the Linux kernel community to help address
this issue and ensure the correct and efficient usage of spin locks in
my kernel module.

Thank you very much for your time and assistance.

-- 
Thanks,
Sekhar

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

             reply	other threads:[~2024-05-09 14:41 UTC|newest]

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

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=CAHhAz+isxCcxq3QLqmapcQwvZDYb-PL7FAi2cFMgFwXVNU2h7g@mail.gmail.com \
    --to=munisekharrms@gmail.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).