lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 May 2024 15:26:34 +0000
From: "Billie Alsup (balsup)" <balsup@...co.com>
To: Muni Sekhar <munisekharrms@...il.com>,
        kernelnewbies
	<kernelnewbies@...nelnewbies.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP
 Error

>From: Muni Sekhar <munisekharrms@...il.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ