> Benjamin LaHaise wrote:
> > a) a process may never block while holding a spinlock
>
> Except the kernel_lock.
It's not a normal spinlock in my world =)
> > b) an interrupt context may never end while still holding a
> > spinlock
>
> Are you sure ? Sure, all the cases I can imagine where you'd hold a
> different number of spinlocks on entry and on exit have "wrong design"
> written all over them (maybe except for managing hot-pluggable CPUs ;-),
> but I don't see where this case would be flagged as strictly illegal.
The only way I can think of this being possible is when one task on one
cpu needs to pass a lock over to another cpu (as you can't pass the
interrupt onto a task on the same processor -> deadlock), but if you do
that from interrupt context, you're going to be completely screwed if the
other cpu happens to be doing a spin_lock_irq on a lock held by the
processor the interrupt occured on (from non-irq context). In short, I
don't think there's a safe way of passing spinlocks across contexts that
is safely deadlock free.
In fact, to take things a bit further, it could be worth adding to the
debugging code for spinlocks the tainting of locks taken by interrupts so
that any caller who trys to take the lock with interrupts enabled gets a
Big Nasty warning -- think of some of the recent spinlock bugs and how
this would've provided a quick and easy means of finding the bugs.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/