Messages in this thread | | | Date | Wed, 9 Aug 2000 11:05:17 -0700 (PDT) | From | Nigel Gamble <> | Subject | Re: potential kernel deadlocks and races |
| |
This is great work you guys are doing!
On Tue, 8 Aug 2000, Seth Andrew Hallem wrote: > We were also wondering if anyone could provide an answer to why > functions should not sleep with spinlocks held. It is easy to see > that this can potentially lead to deadlock, but we are unsure as to > why the "Unreliable Guide" said that you should never do this.
Once you hold a spinlock, you must ensure that there is no way that any sort of context switch can occur to another thread of control that might try to acquire the same spinlock. If this were to happen, the CPU would spin on the lock forever. If a function sleeps with a spinlock held, another task will get to run and potentially try to acquire the same spinlock.
The other way a context switch could happen is if an interrupt occurs while the spinlock is held. This would cause a switch to an interrupt handler, which might try to acquire the same spinlock. (In a fully preemptible kernel, the interrupt could also cause a context switch to another task, which might also try to acquire the same spinlock.) So interrupts are normally (and in a fully preemptible kernel, must be) disabled while a spinlock is held.
If there is no way to reorder the code to avoid calling a sleeping function while the lock is held, a sleeping lock must be used instead of a spinlock.
Nigel
- 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/
| |