[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled

    * Jens Axboe <> wrote:

    > There can quite easily be lots of pending IO for the io_context (and,
    > in CFQ's case, below cfq_io_contexts), task exiting is completely
    > decoupled from any pending io.

    yes, but that only affects the io_context reference count. Actual new
    use of tsk->io_context should only be possible on the IO-submission
    side, which should all have stopped by the time we execute do_exit().
    (and it's synchronous anyway, so the fact that we are executing in the
    kernel prevents the same thread from submitting new IO, in this case.)

    i.e. the removal of tsk->io_context can be done without locking out
    interrupts. No interrupt or io_context is supposed to access
    current->io_context at that point.

    > Then there's the cfq_exit_io_context() locking. I have to ponder this
    > a bit, I cannot even convince myself that it is currently safe right
    > now.

    i think it should be mostly safe already - it seems to be overlocking a
    bit. E.g. the read_lock_irq(&tasklist_lock) could be a simple
    read_lock() i think.

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

     \ /
      Last update: 2005-08-25 09:56    [W:0.053 / U:40.808 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site