[Devel] Re: [PATCH] usbatm: Update to use the kthread api.

[Eric W. Biederman]

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
_______________________________________________
Containers mailing list
Containers at lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers