On Tue, 11 Jul 2006 22:26:47 -0500
"Serge E. Hallyn" <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
