Christoph Hellwig <hch@infradead.org> writes:

> Can you add a little bit of context what all this is about, please?
>
> On Thu, Dec 14, 2006 at 02:36:46PM +0100, Cedric Le Goater wrote:
>> 
>> I've added Christoph to Cc: for his expertise in kthread conversions. 
>> 
>> > ...
>> >
>> > You have a problem with the pid, right?  Well, that is easily
>> > cured in itself.  I'll spin a patch for it a bit later, unless
>> > someone else gets there first.  And if you can confirm that kthread_stop
>> > can be used in this situation (i.e. thread can spontaneously return
>> > without kthread_stop) then I'm happy to convert everyone over to checking
>> > kthread_should_stop.

In the long slow process to build container support in the linux kernel
one of the items on our todo list is the kernel_thread to kthread conversion.

While converting the usbatm driver we hit what is at least a partial snag.
I was hoping to remove the sending of signals along with the rest of
the conversion, but I hit a surprising use.

The usb atm drivers have some long running initializers (several seconds
potentially.   So the infrastructure forks off a kernel thread to run them.

The code really does not care if the thread completes or does anything
else until a usb disconnect comes in.  The in wants to wait suggest the
initialization code stop early and abort and then wait until the
initialization is done.

The practical problem is what is the best way to handle that case.

Can we use the kthread_should_stop() test in a thread that can
exit on it's own before kthread_stop is called?

Are signals the best available mechanism to request that a thread
stop that can exit on it's own.

If we don't suggest to the thread to stop having it call
complete_and_exit seems to the simplest race free solution.  The
request to stop though makes things trickier.


Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers