Re: Question about spin-lock/interrupt/ipl interaction.

[Andrew Doran <ad%netbsd.org@localhost>]

On Wed, Jan 26, 2011 at 11:18:12PM -0800, Matt Thomas wrote:

> Spin locks have the semantics that IPL doesn't get lowered until the last 
> spin lock is unlocked.  For example, taking a IPL_VM spinlock will make sure 
> IPL is at least IPL_VM while the lock is locked.  If then a IPL_SCHED lock is 
> locked, and the current ipl is IPL_VM, ipl is raised to IPL_SCHED.  If the 
> IPL_SCHED lock is unlocked, the ipl stays at IPL_SCHED until the last spin 
> lock is unlocked.  This is done to allow spin-locks to be unlocked in any 
> order.
> 
> Now consider this scenario: a kernel takes a IPL_VM spin lock so IPL is now 
> IPL_VM.  Now an interrupt happens from a IPL_SCHED source so that during 
> execution of the handler a IPL_SCHED spin lock is locked and unlocked leaving 
> IPL_SCHED the current ipl.  In this instance, we know that any spin-locks
> locked in the interrupt handler must be unlocked before the handler returns.
> 
> Now my question is whether the interrupt dispatch code should process 
> interrupt sources higher than IPL_SCHED (honoring the defined spin-lock/ipl 
> semantics) or can it drop IPL back to its original level allowing more 
> IPL_SCHED interrupt sources to be serviced (or not honoring the defined 
> spin-lock/ipl semantics)?
> 
> Why the latter is a violation, it seems wrong to me for a interrupt to return 
> to the code that was interrupted at a different ipl from which it was 
> invoked.  
> 
> Should the spin-locks semantics be modified for interrupt usage?

One of the design assumptions for spin mutexes was that on EOI we restore
the IPL back to what it was at the time the interrupt occurred *, regardless
of what has been done in the ISR.   So it soothes that particular bit of
nastiness with nested locks+IPLs because we're pretty much guaranteed to be
dropping back to low(ish) IPL regularly.  Does that answer the question or 
did you have something else in mind?  I think you might but I'm not sure.

* excluding of course syscalls + traps, must naturally be @ IPL_NONE on
  return there or something has gone all wacky.