kthread_stop on a already completed thread
 

hi,

i am facing one issue in using kthread_stop().

basically i have created one kernel thread using kthread_create(), that threadfn contains small operations which may not take much time.

Now the problem is, i am just using kthread_stop() after creation and wakeup process of the threadfn, by the time of calling kthread_stop() that threadfn already completed its job. now the control is not coming back from this kthread_stop().

how to overcome this problem... and also if i give an invalid pointer to kthread_stop() what will be the behavior and how to overcome it???

thanks,
rajesh

It is not good practice to initiate the end of a thread from more than one context (any type of thread).

You have to decide where the responsibility for stopping the thread lies. If it is within the thread, then it will call do_exit. If it is external to the thread, then the thread will poll kthread_should_stop() until it is true and return.

In other words, you should not call kthread_stop() if the thread itself will exit.

If you just want to wait at the end until the kthread_stop has been called, you might do something like this:

Can you please tell me how to then clean up the thread? I use to terminate the thread (from the thread itself), but I believe the thread becomes a zombie. How do you clean the thread up?

Best to start a new forum thread which will be seen by more people, as this is an old one.

I don't know the answer to your question, and you may need to post more information about your code on the new forum thread.

Incidentally, it is normal for a thread to become a zombie immediately after it exits; the issue is more likely to be something to do with the parent thread causing a problem with the cleanup.

If you have something that needs to be dealt with by a kernel thread, then most likely that thread would be persistent: once started, it would never end. (It might be sleeping.) But, if the thread is a "one-shot," it should in any case be fully the master of its own affairs: it does its work, then it, gracefully and on its own terms, dies. Don't point a pistol at its head. (This principle is IMHO pretty much true for any thread-oriented design, kernel or otherwise. There really is no way to close the timing-holes that otherwise would occur, and those timing holes would cause "random" misbehavior ... for example, in the middle of a very important sales presentation, even after a gaggle of dedicated programmers had been testing it for days.)

@sundialsvcs, The threads start upon initialization of the module and die when the kernel module is removed. They are persistent, but eventually every thread has to die. I am not pointing a pistol at it at all! The thread terminates, no problem.

The thing is, if the thread becomes a zombie, that means the parent needs to tell the OS it doesn't need it anymore, so it would be cleaned up. In pthreads, this is by pthread_join. I wanted to see if with kthreads, there is an equivalent function or not, or if its even needed.

Maybe have it print its pid, maybe even to a file for debugging.

It doesn't sound like you're sure it's left there as a zombie or not, but there is no 'parent' for it to signal so you may not even have a problem?

You may even be able to do a pgrep to see what is in fact running by name.

Best of luck. :-)

@rainbowsally, indeed, I am not sure if the threads become zombies after do_exit or not. I was hoping you could clear it for me.

Well, the thread calling module_init creates the thread, so it's its parent. When it finishes, I guess init will become the threads parent. I believe there is always a parent for the thread. Since it is init, though, there shouldn't be a problem, because init periodically cleans up its terminated children.

Ok, now that I have said it out loud, I understand that there is no need for cleanup. Thread of clean_up is not the thread's parent so it can't cleanup anyway. Is that true?