Possible methods for the kernel to terminate a process

Possible methods for the kernel to terminate a process

[Xiachen Dong]

Hi,

We have a quick question. Besides sending signals, are there any other ways for the kernel to terminate a process?

We have such question because we try to kill a user space process by the shell command kill and we cannot kill it probably because it is in an un-interruptible sleep/wait. 

However, we still wish to be able to kill the user space process under this circumstance. To our knowledge of the kernel, if the kernel wants to kill a process when special event such as exception happens, it usually sends a signal to the process. We really cannot think of any other methods for a kernel to terminate a process.

Can anyone provide some hints on this? Is rebooting the machine the only solution to the problem?

Thanks,

Xiachen

 		 	   		  
_________________________________________________________________
MSN Dating: Find someone special. Start now.
http://go.microsoft.com/?linkid=9734384

Possible methods for the kernel to terminate a process

[Russell King - ARM Linux]

On Tue, Jun 22, 2010 at 03:40:35PM -0400, Xiachen Dong wrote:
> We have such question because we try to kill a user space process by the
> shell command kill and we cannot kill it probably because it is in an
> un-interruptible sleep/wait. 

Some applications block some signals while they wait for events.
SIGKILL is one signal which is unblockable.  Have you tried using
this rather than SIGTERM ?

> However, we still wish to be able to kill the user space process under
> this circumstance. To our knowledge of the kernel, if the kernel wants
> to kill a process when special event such as exception happens, it
> usually sends a signal to the process. We really cannot think of any
> other methods for a kernel to terminate a process.

Sometimes the kernel forcefully exits the task - but that can only happen
while the task's context is running.  If it's in an uninterruptible wait
then it won't be running.

Possible methods for the kernel to terminate a process

[Xiachen Dong]

Thanks for the reply.

Sorry that I forgot to mention that the process does not have any signals blocked. And we have tried sending signal from SIG_1 to SIG_64 to the process and we were still not able to kill it.

We also wrote a simple kernel char diver (say /dev/testKill) for testing purpose. The close() method of the driver does nothing but trying to down() a semaphore that is intentionally initialized to zero. We also wrote a user space program (say userTestKill) to help the test. What userTestKill does is:

1) open the device and then;
2) does the busy sleep forever;

Then we try to kill userTestKill by the shell kill command. We found out that we are not able to kill it because userTestKill will end up calling the close() method of /dev/testKill after it receives the signal (via __exit_files() in do_exit()). However, since down() method is an uninterruptible block/wait, userTestKill can not be killed by any signal.

What we wish to know is whether there are any other methods for the kernel to terminate userTestKill under such situation. We think over it very hard and could not find any. It looks to us like the only possible method is to reboot the machine.

Here is briefly how the driver for /dev/testKill is written:

static int testKill_release( struct inode* inode, struct file* filp )
{
??? ...

??? down( &sem_testKill );??? 

??? ...

??? return 0;
}

int __init testKill_init( void )
{
??? ...
??? // intentionally set the semaphore to zero
??? sema_init(&sem_testKill, 0);
??? ...

??? return 0;
}


Thanks,


Xiachen


----------------------------------------
> Date: Tue, 22 Jun 2010 21:01:52 +0100
> From: linux at arm.linux.org.uk
> To: xiachendong at hotmail.com
> Subject: Re: Possible methods for the kernel to terminate a process
> CC: linux-arm-kernel at lists.infradead.org
>
> On Tue, Jun 22, 2010 at 03:40:35PM -0400, Xiachen Dong wrote:
>> We have such question because we try to kill a user space process by the
>> shell command kill and we cannot kill it probably because it is in an
>> un-interruptible sleep/wait.
>
> Some applications block some signals while they wait for events.
> SIGKILL is one signal which is unblockable. Have you tried using
> this rather than SIGTERM ?
>
>> However, we still wish to be able to kill the user space process under
>> this circumstance. To our knowledge of the kernel, if the kernel wants
>> to kill a process when special event such as exception happens, it
>> usually sends a signal to the process. We really cannot think of any
>> other methods for a kernel to terminate a process.
>
> Sometimes the kernel forcefully exits the task - but that can only happen
> while the task's context is running. If it's in an uninterruptible wait
> then it won't be running.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 		 	   		  
_________________________________________________________________
Turn down-time into play-time with Messenger games
http://go.microsoft.com/?linkid=9734385

Possible methods for the kernel to terminate a process

[Russell King - ARM Linux]

On Tue, Jun 22, 2010 at 05:05:53PM -0400, Xiachen Dong wrote:
> Sorry that I forgot to mention that the process does not have any
> signals blocked. And we have tried sending signal from SIG_1 to SIG_64
> to the process and we were still not able to kill it.
> 
> We also wrote a simple kernel char diver (say /dev/testKill) for testing
> purpose. The close() method of the driver does nothing but trying to
> down() a semaphore that is intentionally initialized to zero. We also
> wrote a user space program (say userTestKill) to help the test. What
> userTestKill does is:
> 
> 1) open the device and then;
> 2) does the busy sleep forever;
> 
> Then we try to kill userTestKill by the shell kill command. We found
> out that we are not able to kill it because userTestKill will end up
> calling the close() method of /dev/testKill after it receives the
> signal (via __exit_files() in do_exit()).

Yes - the kernel is trying to free the resources which were in use by
the program.

I think what you're really asking is "I'd like to be able to kill a
program _and_ leak the resources it's using, possibly rendering them
inoperative for use by future programs."

That's possible with a few kernel hacks - all you really need to do is
to arrange for the kernel to forget that the program ever existed.

However, I suspect that you don't actually want this - you want to be
able to terminate a program and free its resources, even if freeing
those resources ends up blocking with an uninterruptible wait.  I
don't think that's possible.

The other issue here is that blocking in close() like this is a very
bad thing - even with an interruptible wait there, if you could be
interrupted in __exit_files(), there's no recovery from an interrupted
wait, and you'll end up leaking resources (and if you did try to call
exit() from within __exit_files(), you'll find that the kernel will
throw a fit with "Fixing recursive fault but reboot is needed!".)

Possible methods for the kernel to terminate a process

[Jamie Lokier]

Xiachen Dong wrote:
> 
> Hi,
> 
> We have a quick question. Besides sending signals, are there any other ways for the kernel to terminate a process?
> 
> We have such question because we try to kill a user space process by the shell command kill and we cannot kill it probably because it is in an un-interruptible sleep/wait. 
> 
> However, we still wish to be able to kill the user space process under this circumstance. To our knowledge of the kernel, if the kernel wants to kill a process when special event such as exception happens, it usually sends a signal to the process. We really cannot think of any other methods for a kernel to terminate a process.
> 
> Can anyone provide some hints on this? Is rebooting the machine the only solution to the problem?

You can't kill a task that's in TASK_UNINTERRUPTIBLE state, except by
the condition the task is waiting on changing.

That's been a well known problem with unix for decades, because
uninterruptible wait is used for some things (like reading a disk
file) that it seems reasonable to be able to kill.

So, to fix that, TASK_KILLABLE was added.  It means you can't
interrupt the process with most signals, but you can at least "kill
-9" the process (SIGKILL).

I think for what you're asking, if the problem is some processes tend
to block on particular device drivers, or processes blocked while
accessing files gets stuck, or things like that, the best thing is to
look at the places they might be in TASK_UNINTERRUPTIBLE and
*carefully* change the code to use TASK_KILLABLE and handle the killed
condition.

It's not possible to just search-and-replace TASK_UNINTERRUPTIBLE.
You have to make sure the killed condition is handled by cleaning up
locked resources, and only then change to killable.

-- Jamie

Possible methods for the kernel to terminate a process

[Xiachen Dong]

Thank you very much for the reply. It's very helpful.

I didn't noticed that TASK_KILLABLE(TASK_WAITKILL | TASK_UNINTERRUPTIBLE) is already defined in sched.h and I didn't know that there is such a state either.

I'll do some more testing with the simple test driver code.

Thanks,

Xiachen

----------------------------------------
> Date: Wed, 23 Jun 2010 01:44:22 +0100
> From: jamie at shareable.org
> To: xiachendong at hotmail.com
> Subject: Re: Possible methods for the kernel to terminate a process
> CC: linux-arm-kernel at lists.infradead.org
>
> Xiachen Dong wrote:
>>
>> Hi,
>>
>> We have a quick question. Besides sending signals, are there any other ways for the kernel to terminate a process?
>>
>> We have such question because we try to kill a user space process by the shell command kill and we cannot kill it probably because it is in an un-interruptible sleep/wait.
>>
>> However, we still wish to be able to kill the user space process under this circumstance. To our knowledge of the kernel, if the kernel wants to kill a process when special event such as exception happens, it usually sends a signal to the process. We really cannot think of any other methods for a kernel to terminate a process.
>>
>> Can anyone provide some hints on this? Is rebooting the machine the only solution to the problem?
>
> You can't kill a task that's in TASK_UNINTERRUPTIBLE state, except by
> the condition the task is waiting on changing.
>
> That's been a well known problem with unix for decades, because
> uninterruptible wait is used for some things (like reading a disk
> file) that it seems reasonable to be able to kill.
>
> So, to fix that, TASK_KILLABLE was added. It means you can't
> interrupt the process with most signals, but you can at least "kill
> -9" the process (SIGKILL).
>
> I think for what you're asking, if the problem is some processes tend
> to block on particular device drivers, or processes blocked while
> accessing files gets stuck, or things like that, the best thing is to
> look at the places they might be in TASK_UNINTERRUPTIBLE and
> *carefully* change the code to use TASK_KILLABLE and handle the killed
> condition.
>
> It's not possible to just search-and-replace TASK_UNINTERRUPTIBLE.
> You have to make sure the killed condition is handled by cleaning up
> locked resources, and only then change to killable.
>
> -- Jamie
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 		 	   		  
_________________________________________________________________
Learn more ways to connect with your buddies now
http://go.microsoft.com/?linkid=9734388