hello...
> for_each_process(task)
> {
Better use find_task_by_pid()....after all you do have the target pid,
right? :)
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.
BTW, you do execute the "kill" as root, right?
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?
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()?
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
>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/
