[lkml]   [2006]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: please revert kthread from loop.c
    On Tue, 11 Jul 2006 22:26:47 -0500
    "Serge E. Hallyn" <> wrote:

    > > If so, this should plug it. The same race is not possible against the
    > > loop_set_fd() wakeup because the thread isn't running at that stage, yes?
    > Right, it's not yet running at loop_set_fd(). However what about
    > kthread_stop() called from loop_clr_fd()? Unfortunately fixing
    > that seems hairy. Need to think about it...

    Yes, there does seem to be a little race there.

    I think it would be sufficient to do

    diff -puN drivers/block/loop.c~a drivers/block/loop.c
    --- a/drivers/block/loop.c~a
    +++ a/drivers/block/loop.c
    @@ -602,7 +602,8 @@ static int loop_thread(void *data)
    - schedule();
    + if (lo->state != Lo_rundown)
    + schedule();

    return 0;
    @@ -888,12 +889,11 @@ static int loop_clr_fd(struct loop_devic
    if (filp == NULL)
    return -EINVAL;

    + kthread_stop(lo->lo_thread);
    lo->lo_state = Lo_rundown;

    - kthread_stop(lo->lo_thread);
    lo->lo_backing_file = NULL;

    where the tweak to loop_clr_fd() is just there to prevent loop_thread()
    from going into a very brief busyloop.

    I'm not sure why it's all so tricky in there, really. Loop is doing a
    pretty conventional stop, wakeup, stick-things-on-lists operation and we do
    that all over the kernel using pretty well-understood idioms. But for some
    reason, loop is all difficult about it. I wonder why. hm.
    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: 2006-07-12 05:49    [W:0.023 / U:3.576 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site