Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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???
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:
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.)
Last edited by sundialsvcs; 04-17-2012 at 08:48 AM.
@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.
@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?