Messages in this thread Patch in this message | | | Date | Tue, 11 Jul 2006 20:46:37 -0700 | From | Andrew Morton <> | Subject | Re: please revert kthread from loop.c |
| |
On Tue, 11 Jul 2006 22:26:47 -0500 "Serge E. Hallyn" <serue@us.ibm.com> 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) } __set_current_state(TASK_INTERRUPTIBLE); spin_unlock_irq(&lo->lo_lock); - 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); spin_lock_irq(&lo->lo_lock); lo->lo_state = Lo_rundown; spin_unlock_irq(&lo->lo_lock); - kthread_stop(lo->lo_thread); - lo->lo_backing_file = NULL; loop_release_xfer(lo); _ 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |