On Friday 15 December 2006 11:45, Eric W. Biederman wrote: > Christoph Hellwig <hch at infradead.org> writes: > > > On Fri, Dec 15, 2006 at 03:17:57AM -0700, Eric W. Biederman wrote: > > > > I think the right fix is to encehance the kthread infrastructure to > > gracefully handle the case where the threat has stopped by itself > > and doesn't exist anymore at the time where we call kthread_stop. > > Yep that is about where I thought we were at. Now we need to figure out > how to do that cleanly, and sanely. There's a completely different solution, which is to use a workqueue instead of a kthread, with users providing a cancellation method. Recall that the functionality is provided by usbatm to drivers: they use it to perform slow initialization that is too slow to be done in the probe method. They register with usbatm, providing a "heavy_init" method. They could also provide a "heavy_cancel" method. (Any special data that heavy_cancel needs can be stored in the existing driver private data structure; this structure is already passed to heavy_init). In the case of the speedtch driver, it could place a completion in its private data structure; heavy_cancel would just complete the completion. Rather than doing interruptible sleeps, it can use wait_for_completion_timeout. The only thing that worries me about this solution is... that you can't shoot down firmware loading from userspace anymore. For example, if heavy_init is blocked loading firmware when the system is halted, it presumably won't react to the kill signal. Perhaps it is unimportant; and if not, I guess I can just re-enable signals in heavy_init. Ciao, Duncan.
