RE: kernel_thread vs. zombie

["Martin Frey" <frey@scs.ch>]

Hi,
>> http://www.scs.ch/~frey/linux/kernelthreads.html

>Could you explain me a bit why you need the lock_kernel ? My probe
>thread is already protected by some atomic ops, but I'm considering
>changing them to semaphores. Is there any need for the bkl to be taken
>when calling daemonize or is this just for your own 
>syncronisation needs ?
>
The stuff done in daemonize() and the exit_files could need
the kernel lock. At least on some 2.2.x version it does,
I did not check whether it is still needed on 2.4.

On stop of the thread I need the big kernel lock to make
sure the kernel thread exited (everything really done
from my up() till the thread is in zombie state) before
I unload the module. The comment in the code should explain 
in.

Note that the threads itself do not run with the kernel lock
held. After setting everything up the make an unlock.

>I don't think you do more than what I currently do to prevent the
>zombie (except for the daemonize call, I don't see you 
>changing anything
>about the parent thread or whatever). 
>
No, changing the parent thread is done by daemonize().

>At first I though daemonize() would do the trick, but I still see
>zombies on my tests. I'm running UP now so I don't since my lack
>of lock_kernel() could explain it.
>
I needed the exit_files() on 2.2.x to prevent the zombies. On 2.4
daemonize() does that as well.

In the kill_thread() call I actually wait till the thread has
terminated. This is assured with the semaphore and the big kernel
lock. I did have problems when I just sent the termination signal
and unloaded the module, but since I really block there I did not
see zombies. I stress-tested the module for several days in a loop
- no zombies at all.

Regards,

Martin