Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
hello...Hi Mulyadi,
> for_each_process(task)
> {
Better use find_task_by_pid()....after all you do have the target pid,
right? :)
<Raja> First of all, thanks for the interesting response.
Yes, I am now using find_task_by_pid() as per your advice.
About the state transition, may I ask something? Do you run these codes
on SMP or HT machine? if yes, maybe the state is still on
TASK_UNINTERRUPTIBLE state. Try to use set_task_state() instead that
might solve the problem. It will detect if the code is running on SMP
environment and will force atomic memory write via memory barrier.
<Raja> I am running the code on a single processor machine.
BTW, you do execute the "kill" as root, right?
<Raja> Yes, I "killed" as root only.
Personally for me, it is a bit strange that interruptible state is
allowed to be altered into uninterruptible state while it is forbidden
to do the reverse thing. rajaram, can you check the following case:
1. is the process already in interruptible state?
<Raja> I am not sure I got your question. Yes, the parent process (bash) should be in TASK_INTERRUPTIBLE state after we issue insmod.
2. Since you are manipulating other process state, I think you need to
grab a lock. I don't have clever ideas here, maybe task_struct->
switch_lock grabbed by spin_lock_irq()?
<Raja> sorry, I am too new to play with these spin locks etc.
3. To support Jan's theory, try to convert the state back to
TASK_RUNNING first. use set_task_state() and activate_task() to do this
<Raja>
The following are my observations today.
I began to use set_task_state() wherever I try to change state of the process.
1. In the init_module, as before, I changed the state of the parent (ie bash) to TASK_UNITERRUPTIBLE. Now , the bash hung, as it was not able to receive any signals.
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().
Now these are my questions.
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.
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.
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 case !!?? <Raja>
From here, i think slowly we will know the real problem and perhaps
reveal the state transition enforced by Linux kernel.
Hope it helps
regards
Mulyadi
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
First of all , thanks for the interesting details.
Yes, I replaced the for_each_process() loop with find_task_by_pid() as per your advice.
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping
