[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.019 / U:5.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site