Please look in to my latest reply below with tag <Raja1>.
Rajaram Suryanarayanan <rajaram_linux@xxxxxxxxx> wrote:
Rajaram Suryanarayanan <rajaram_linux@xxxxxxxxx> wrote:
Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:Hi Rajaram....
Sorry for this late reply.
>I am running the code on a single processor machine.
But not a HyperThreading based processor, am I right?<Raja> Yes, I dont think my company gave me a HT processor :)
<Raja1> hey, just now I asked my IT people. They tell my machine is P4 HT enabled.
>I am not sure I got your question. Yes, the parent process
> (bash) should be in TASK_INTERRUPTIBLE state after we issue insmod.
what I mean is, after the task (bash) is set back to
TASK_INTERRUPTIBLE, is it really back to TASK_INTERRUPTIBLE? or still
at TASK_UNINTERRUPTIBLE?<Raja> Since I was able to kill the process, I believe that it came back to TASK_INTERRUPTIBLE.
> 2. In another console, I inserted a module to find the hung bash
> process and changed its state again to TASK_INTERRUPTIBLE.
> 3. Now I issued "kill -9" to kill the bash process.
> 4. It worked !!! the bash process was killed . I think this was
> due to that I used the correct way to change the process state i.e
> set_task_state().
if that's the only thing you did, then yes....big chance
set_task_state() is indeed doing the right job for you. But still, this
makes me think...if you check the macro declaration, on UP, actually it
does the same thing like task_struct->state=. The only thing
that differs is when it is used on SMP/HT....<Raja> may be set_task_state does that by acquiring some lock properly..?? just a wild guess.
> 1. Since the bash process received SIGKILL successfuly, it means
> it has successfuly changed back from TASK_UNITERRUPTIBLE to
> TASK_INTERRUPTIBLE. But after coming back to TASK_INTERRUPTIBLE
> state, why did it not receive/notice the SIGCHLD signal that insmod
> has already sent it long back before we inserted the second module
> ...? If this had been done, it would have come to the normal bash
> prompt..But this did not happen.
IIRC, SIGCHLD notice the parent (bash) to do the clean up (to destroy
the rest of insmod's task structure), so IMHO it actually received it
and did the job. You did see the insmod process no longer exists and
there is no zombie process, right? CMIIW<Raja> hmm..I have to check whether insmod was not in zombie state. But if the bash process received SIGCHLD and cleaned up insmod properly.., it should have come to the next bash prompt.., right..?
<Raja1> I checked. insmod was still in zombie state.
> 2. Also I repeated all the steps again with a small change that I
> tried changing the state from TASK_UNINTERRUPTIBLE to TASK_RUNNING in
> the step 2 above. Now even "kill -9" did not work.
IIRC, you also need to insert the task back to the runqueue... Study
the activate_task() function (or maybe enqueue_task()?)<Raja> Yes. I will try to do that.
<Raja1> Yes. I tried that. I used wake_up_process() and the hung up bash process came back to the prompt without the need of killing that.
Now, I guess that when you wake up the process, it comes from the TASK_UNINTERRUPTIBLE state back to TASK_RUNNING and gets in to runnable queue. When it is then scheduled to run, it sees that SIGCHLD is waiting for it and then receives the signal, cleans up the insmod zombie and then comes to the next bash prompt.
May be it is also like this : when we try to convert back the state from TASK_UNINTERRUPTIBLE to TASK_INTERRUPTIBLE, it need not notice the pending SIGCHLD signal ( infact any signal ). But only respond when we force kill it using kill -9.
hmm..these are all my guesses..need to actually patiently look in to the code and understand :) <Raja1>
> 3. A new question. Pls forget above all the things above.
> I just tried current->parent->parent = current. That is I tried to
> change the parent of bash to insmod ( dirty thing to do, I know :) ).
> Now the whole system hung..keyboard / mouse did not respond...even I
> was not able to switch off the PC by pressing the button. I had to
> switch off the power supply !!. What happened in this
Hehe :) You are messing up with "init" process. See, parent of insmod is
bash, parent of bash is init :) So, actually you do "task_struct of
init is set to task_struct of current process", got the picture now? :D<Raja> No. I am not doing anything to init process descriptor.I am doing bash->parent = insmod. i.e I am just setting the parent pointer of bash to point to its child...i.e insmod. So that bash thinks that insmod is its parent.
regards
Mulyadi
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
Yahoo! for Good - Make a difference this year.
Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.
