[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.036 / U:13.196 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site