Received-SPF: pass (google.com: domain of linux-kernel+bounces-174598-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
From: Muni Sekhar <munisekharrms@gmail.com>
Date: Thu, 9 May 2024 20:09:13 +0530
Message-ID: <CAHhAz+isxCcxq3QLqmapcQwvZDYb-PL7FAi2cFMgFwXVNU2h7g@mail.gmail.com>
Subject: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error
To: kernelnewbies <kernelnewbies@kernelnewbies.org>, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

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