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/
