[lkml]   [1997]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Race conditions galore (2.0.33 and possibly 2.1.x)
    Bill Hawes wrote:
    >Stephen R. van den Berg wrote:
    >> Could someone who created these wait-queue loops (there are several of them
    >> in the kernel, potentially all of them are race conditions waiting to
    >> happen) confirm if I'm reading this correctly? Maybe I still overlooked
    >> possible problems, but it seems like this is the minimally-correct change.

    >In this particular case the existing code should be OK. The reason you
    >don't need to set the task state to TASK_UNINTERRUPTIBLE in advance is
    >that we have a test available for whether to do the reschedule: if the
    >buffer is already unlocked, there's no need to schedule. In the event an


    >interrupt occurs in between the test for buffer locked and the
    >schedule() call, the resulting wakeup() will set the task state back to
    >TASK_RUNNING, and we'll fall through the schedule().

    This I'm not certain about. I only performed a cursory check of schedule.c,
    but it seems that when the task is still on the run-queue (which it is,
    before it hits schedule()), the task state will *not* be set back to

    Also, what happens if the same buffer is:
    1. Locked.
    2. We add ourselves to the wait queue.
    3. The buffer is unlocked.
    4. We are set to TASK_RUNNING.
    5. Someone else locks the buffer.
    6. We set ourselves to TASK_UNINTERRUPTIBLE.
    7. We check the lock.
    8. We drop dead in schedule().

    Or am I seeing ghosts?

    Note: I wouldn't be beating around about this so much, if it weren't
    for the fact that I have a machine here that actually *repeatedly*
    had processes hanging in constructs like this. I patched it as described,
    and the problems have not recurred yet (maybe that's just a coincidence,
    or maybe I even did something I shouldn't have been doing in the first

    The only other thing it could be would be a hardware-failure of some
    kind (RAM-biterrors being unlikely, I'm using ECC; most likely something
    strange the SCSI driver was not expecting; but, the kernel did not log
    a single error).
    Stephen R. van den Berg (AKA BuGless).

    "Father's Day: Nine months before Mother's Day."

     \ /
      Last update: 2005-03-22 13:40    [W:0.044 / U:19.420 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site