Alan Stern <[email protected]> writes:
> Here's a question about how to use a kthread.
>
> The usb-storage driver creates a new thread to do LUN scanning whenever a
> newly-hotplugged device is detected. This scanning involves waiting for
> several seconds and then carrying out a potentially long-lasting series of
> I/O operations. So we don't want to use schedule_work(); instead we
> create a new thread to do it.
>
> Once the scanning thread's work is done, there's no reason for it to hang
> around. The driver's probe() method has long since exited, leaving nobody
> to reap the thread. Of course it could always just exit normally, without
> checking kthread_should_stop(), but...
>
> If the device is unplugged during that initial several-second-long delay
> period, we need to stop the scanning thread immediately. The obvious
> answer is to use kthread_stop(), but that's not consistent with the
> thread's normal behavior of exiting without waiting for
> kthread_should_stop().
>
> Another problem arises as well. If the driver's remove() method doesn't
> call kthread_stop() then it doesn't have any straightforward way to wait
> for the thread to exit. This leads to the possibility that the driver's
> module could be unloaded while the scanning thread is still running.
>
> Would the best approach be to set up a special-purpose struct completion?
> Then the thread could call complete_and_exit() and the remove() method
> could wait for it safely.
Ok. Because of the module unloading issue, and because we don't have
a lot of these threads running around, the current plan is to fix
thread_create and kthread_stop so that they must always be paired,
and so that kthread_stop will work correctly if the task has already
exited.
Basically that just involves calling get_task_struct in kthread_create
and put_task_struct in kthread_stop.
I have some patches, hopefully I will start getting them out in the next day or
two. Sorry I should have acted on this sooner, but I got a little distracted.
Eric
-
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]
