title: spin_lock_irqsave() in interrupt context
body: <p>I'm maintaining a driver which shares some resource between the ISR (i.e., in interrupt context) and the <code>read()</code> syscall.  In both cases, <code>spin_lock_irqsave()</code> is used, since (obviously) the resource can be acquired in the interrupt context.</p>
  
  <p>However, I was wondering if using <code>spin_lock_irqsave()</code> is necessary in the interrupt context.  Namely, the Unreliable Guide to Locking (see here: <a href="https://kernel.readthedocs.io/en/sphinx-samples/kernel-locking.html" rel="nofollow noreferrer">https://kernel.readthedocs.io/en/sphinx-samples/kernel-locking.html</a>) states:</p>
  
  <blockquote>
    <p>Note that the <code>spin_lock_irqsave()</code> will turn off interrupts if they are on, otherwise does nothing (if we are already in an interrupt handler), hence these functions are safe to call from any context.</p>
  </blockquote>
  
  <p>As a result, is it common practice to use "normal" <code>spin_lock()</code> in the interrupt handler (since the particular interrupt is already disabled) and then call <code>spin_lock_irqsave()</code> in the user context?  Alternatively, is the better practice to just use <code>spin_lock_irqsave()</code> everywhere?  I'm leaning towards the latter, for two reasons:</p>
  
  <ol>
  <li>As soon as someone sees that a lock is acquired with <code>spin_lock_irqsave()</code>, it's obvious that the lock is intended to be shared with the interrupt context.</li>
  <li>As someone maintaining the code, you don't have to ensure whether or not a particular function is going to be called in what context.  Said differently, using <code>spin_lock_irqsave()</code> works in any context, so you don't have to ensure that a function is only called in a certain context.</li>
  </ol>
  
  <p>With the above said, I'm wondering what the convention/best practice is for code that resides in kernel space.  Is it better to use <code>spin_lock_irqsave()</code> everywhere the lock is acquired, even if you can guarantee that the lock is being acquired from the interrupt context?</p>