[lkml]   [2000]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: One more boobytrap needed for 2.2.15pre ?
    [cc'ed back to lk]
    I have one _idea_ what could have happened:

    1) thread is running with TASK_INTERRUPTIBLE
    2) calls schedule()
    3) schedule calls del_from_runqueue()
    4) ...
    5) can't find a new task, jumps to recalculate
    6) enables interrupts
    7) interrupt
    8) XXXXXXXXXXXXXX: someone changes current->state from within the interrupt.
    current->state now TASK_RUNNING
    9) interrupt returns
    10) recalculate finishes, jumps to repeat_schedule().
    11) prev->state == TASK_RUNNING, so current is selected
    12) a task that's not on the runqueue is selected!!!!!!!!!

    Ok, but now the question is: which interrupt changes current->state? Perhaps
    a special boobytrap in the interrupt handlers could detect that?

    in arch/i386/kernel/irq.c:
    * store "current->state" in a special local variable.
    * always change it to TASK_INTERRUPTIBLE.
    * before returning: check if someone changed current->state
    * restore the old value.


    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:56    [W:0.020 / U:39.472 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site