Duncan Sands <baldrick at free.fr> writes: > Hi Eric, > > presumably the problem is that if the thread has spontaneously exited, and > afterwards disconnect calls kthread_stop, then things go boom. The same > problem exists (though with lesser consequences) when sending a signal. > There is already code in usbatm to avoid this problem with signals. Why > not just recycle it in the kthread_stop case? I guess there is no > problem if you can guarantee that the following occurs: > if kthread_stop is ever called for the kthread, then the kthread only > exits after seeing kthread_should_stop return true. I suspect we can recycle the locking on the signal sending code. At least as a first pass. I have almost digested the problem sufficiently to write some code. Maybe this weekend. >> To be clear I have a problem with using numeric pids of kernel threads, > > Yes, this is a problem with usbatm at the moment. > >> and with spawning threads from a possibly user space environment. > > Not the case with usbatm. It is always spawned from khubd. That is where I thought we were at, doing the conversion so it is obvious and we can remove the use of kernel_thread and daemonize would certainly be good. The more shared infrastructure we can reasonably have the more likely the code will function correctly. Eric