Re: Stopping Kernel Threads at module unload time

["linux-os \(Dick Johnson\)" <linux-os@analogic.com>]

On Wed, 9 Nov 2005, Aritz Bastida wrote:

>>
>>> Now, if I call kthread_stop() in module unload time, does that code
>>> run in user process context just like system calls do? That is
>>> important, because if it cannot sleep, it would deadlock.
>>>
>>
>> Not relevent. You have apparently made up your mind that you
>> need to do it "your" way. Fine.
>
> No, no, that is not MY way. That is the 2.6 way.
> (see http://lwn.net/Articles/64444/).
>
> With the old API (kernel_thread) there was no way (at least, direct
> way) to bind a thread to a cpu, which i actually need. And this is not
> MY own approach , it is used throught the kernel:
>
> * migration thread at sched.c:
>           http://lxr.linux.no/source/kernel/sched.c#L4196
>
> * ksoftirqd thread at softirq.c:
>           http://lxr.linux.no/source/kernel/softirq.c#L350
>
> * worker thread used in workqueues:
>           http://lxr.linux.no/source/kernel/workqueue.c#L182
>
> ...and so on
>
> All these threads are standard and well debugged, and all use the API
> which I was talking about. Of course, as they are included in the
> official kernel sources, none of them is stopped at module unload
> time.
>
> Thus, all I want to know is why kthread_stop() cant be called at
> module unload time, if the cleanup code can sleep and if there is a
> workaround for that.
>
> I hope my questions are clearer now.
> Thanks for your help

Then if you are going to use the macros to bind to a certain CPU
when you start up a kernel thread, then you need to use the
complimenting macros to run them down.

You need to use the for_each_cpu() stuff to pick up each thread.
Then you may actually get to talk to the right process.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.