On Tue, 6 Jan 2009, Peter Zijlstra wrote: > > > > In fact, I suspect that's the real bug you're hitting: you're enabling > > preemption while holding a spinlock. That is NOT a good idea. > > spinlocks also fiddle with preempt_count, that should all work out - > although granted, it does look funny. It most certainly doesn't always work out. For example, the irq-disabling ones do *not* fiddle with preempt_count, because they disable preemption by just disabling interrupts. So doing preempt_enable() inside such a spinlock is almost guaranteed to lock up: because the preempt_enable() will now potentially call the scheduler with a spinlock held and with interrupts disabled. That, in turn, can cause any number of problems - deadlocks with other processes that then try to take the spinlock that didn't get released, but also deadlocks with interrupts, since the scheduler will enable interrupts again. So mixing preemption and spinlocks is almost always a bug. Yes, _some_ cases work out ok, but I'd call those the odd ones. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html