[lkml]   [2000]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:0.033 / U:6.876 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site