Hi Darshan :) On Thu, Jan 19, 2012 at 14:03, Darshan Ghumare <darshan.ghumare@gmail.com> wrote:
Hi Mulyadi,
How SIGKILL is handle by Kernel? Does SIGKILL & SIGTSTP handled separately than the rest of the signals?
I hope you don't mind if I cc this answer to kernelnewbies as well. Hopefully you will get better answer. Well, SIGKILL is handled like other usual signal. The important point to notice is that sigkill is handled entirely in kernel space. What it means is that it cannot be overriden in user space (i.e installing your own signal handler). SIGKILL will tell the target process to terminate itself. So it pretty much will flow like normal process termination. However, the termination will be a bit rough. It will just kill....no time to wait for in flight I/O whatsoever. SIGSTOP...ehm, I think that is handled in kernel space too. The handler will basically move the process out of from run queue to the process stopped queue (or something like that, I forgot). Then it switch the process state from "running" to "stop". It's not the same like "sleep" btw. Hope it helps.... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Hi Mulyadi, On Thu, Jan 19, 2012 at 2:16 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com>wrote:
Hi Darshan :)
On Thu, Jan 19, 2012 at 14:03, Darshan Ghumare <darshan.ghumare@gmail.com> wrote:
Hi Mulyadi,
How SIGKILL is handle by Kernel? Does SIGKILL & SIGTSTP handled separately than the rest of the signals?
I hope you don't mind if I cc this answer to kernelnewbies as well. Hopefully you will get better answer.
No.
Well, SIGKILL is handled like other usual signal. The important point to notice is that sigkill is handled entirely in kernel space. What it means is that it cannot be overriden in user space (i.e installing your own signal handler).
SIGKILL will tell the target process to terminate itself. So it pretty much will flow like normal process termination. However, the termination will be a bit rough. It will just kill....no time to wait for in flight I/O whatsoever.
What if, there is one process which is in middle of a syscall which has infinite loop in it received SIGKILL & there are no other processes in the system?
SIGSTOP...ehm, I think that is handled in kernel space too. The handler will basically move the process out of from run queue to the process stopped queue (or something like that, I forgot). Then it switch the process state from "running" to "stop". It's not the same like "sleep" btw.
Hope it helps....
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Hi again :) On Thu, Jan 19, 2012 at 16:03, Darshan Ghumare <darshan.ghumare@gmail.com> wrote:
What if, there is one process which is in middle of a syscall which has infinite loop in it received SIGKILL & there are no other processes in the system?
infinite loop such as "for(;;)" ? well as long as it doesn't disable or masked out the timer interrupt, sooner or later timer interrupt will kick in. It then followed by the usual tick handler. Inside it, IIRC, will provoke the current running process to check queued signal and handle it. if the process then killed and no other process is running (are you sure? not even kernel threads?), then kernel will enter idle state. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Hi, On Thu, Jan 19, 2012 at 7:26 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi again :)
On Thu, Jan 19, 2012 at 16:03, Darshan Ghumare <darshan.ghumare@gmail.com> wrote:
What if, there is one process which is in middle of a syscall which has infinite loop in it received SIGKILL & there are no other processes in the system?
infinite loop such as "for(;;)" ? well as long as it doesn't disable or masked out the timer interrupt, sooner or later timer interrupt will kick in. It then followed by the usual tick handler. Inside it, IIRC, will provoke the current running process to check queued signal and handle it.
If the process was in an infinite loop in user space, what Mulyadi says is true. If it were a real-time process in an infinite loop then it might very well be unkillable (unless there is a higher priority thread which can do the killing). My understanding is that in kernel space signals only get handled when you run into code which specifically deals with signals. All of the syscalls are wrapped with such code. So, if you're in an infinite loop in kernel space, then you're in essentially the same situation as doing a non-interruptible down which never completes. If the kernel were to kill the process just because a preemption occurred (while in kernel space) then you would very often be killing processes which are currently holding a semaphore or something and leaving the kernel in a potentially unstable state. There is always at least one runnable thread, called the idle thread. There is an idle thread for each CPU. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
On Thu, Jan 19, 2012 at 10:54 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi, On Thu, Jan 19, 2012 at 7:26 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi again :)
On Thu, Jan 19, 2012 at 16:03, Darshan Ghumare <darshan.ghumare@gmail.com> wrote:
What if, there is one process which is in middle of a syscall which has infinite loop in it received SIGKILL & there are no other processes in the system?
infinite loop such as "for(;;)" ? well as long as it doesn't disable or masked out the timer interrupt, sooner or later timer interrupt will kick in. It then followed by the usual tick handler. Inside it, IIRC, will provoke the current running process to check queued signal and handle it.
If the process was in an infinite loop in user space, what Mulyadi says is true. If it were a real-time process in an infinite loop then it might very well be unkillable (unless there is a higher priority thread which can do the killing).
My understanding is that in kernel space signals only get handled when you run into code which specifically deals with signals. All of the syscalls are wrapped with such code. So, if you're in an infinite loop in kernel space, then you're in essentially the same situation as doing a non-interruptible down which never completes.
If the kernel were to kill the process just because a preemption occurred (while in kernel space) then you would very often be killing processes which are currently holding a semaphore or something and leaving the kernel in a potentially unstable state.
There is always at least one runnable thread, called the idle thread. There is an idle thread for each CPU.
What if, spin_lock_irqsave(&lock, flags); for ( ; ; ) { ; } spin_lock_irqrestore(&lock, flags);
-- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
-- Darshan®
Hi Darshan, Replying to all this time.... On Thu, Jan 19, 2012 at 9:41 PM, Darshan Ghumare <darshan.ghumare@gmail.com> wrote: ...snip...
What if, spin_lock_irqsave(&lock, flags); for ( ; ; ) { ; } spin_lock_irqrestore(&lock, flags);
Since you're using spinlocks and disabling interrupts, this would be running in kernel space. On a single core machine - you'll have locked up your entire computer. On a multi-core machine you'll have locked up one core. You don't need to use the spinlock, just disabling interrupts is sufficient. Even on a multicore machine, the spinlocks would just prevent a second core from executing the code if it tried to acquire the same spinlock. I don't think that there is any convenient way to kill such a thread. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
On Fri, Jan 20, 2012 at 12:32 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Darshan,
HI Dave,
Replying to all this time....
Thanks.
On Thu, Jan 19, 2012 at 9:41 PM, Darshan Ghumare <darshan.ghumare@gmail.com> wrote: ...snip...
What if, spin_lock_irqsave(&lock, flags); for ( ; ; ) { ; } spin_lock_irqrestore(&lock, flags);
Since you're using spinlocks and disabling interrupts, this would be running in kernel space.
On a single core machine - you'll have locked up your entire computer.
On a multi-core machine you'll have locked up one core.
You don't need to use the spinlock, just disabling interrupts is sufficient. Even on a multicore machine, the spinlocks would just prevent a second core from executing the code if it tried to acquire the same spinlock.
I don't think that there is any convenient way to kill such a thread.
IMHO, signals are handled when process is about to switch back to user-mode. If that is the case then what if, there are two threads(in user-mode) in the process where one is stuck in the syscall which has infinite loop & other is executing some task in the user-mode, then still this process can not be killed?
-- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
Regards Darshan -- Darshan®
Hi Darshan, On Sat, Jan 21, 2012 at 7:31 PM, Darshan Ghumare <darshan.ghumare@gmail.com> wrote:
On Fri, Jan 20, 2012 at 12:32 PM, Dave Hylands <dhylands@gmail.com> wrote: ...snip...
On Thu, Jan 19, 2012 at 9:41 PM, Darshan Ghumare <darshan.ghumare@gmail.com> wrote: ...snip...
What if, spin_lock_irqsave(&lock, flags); for ( ; ; ) { ; } spin_lock_irqrestore(&lock, flags);
Since you're using spinlocks and disabling interrupts, this would be running in kernel space.
On a single core machine - you'll have locked up your entire computer.
On a multi-core machine you'll have locked up one core.
You don't need to use the spinlock, just disabling interrupts is sufficient. Even on a multicore machine, the spinlocks would just prevent a second core from executing the code if it tried to acquire the same spinlock.
I don't think that there is any convenient way to kill such a thread.
IMHO, signals are handled when process is about to switch back to user-mode. If that is the case then what if, there are two threads(in user-mode) in the process where one is stuck in the syscall which has infinite loop & other is executing some task in the user-mode, then still this process can not be killed?
The one that's stuck in the infinite loop will essnetially lockup one core. If you have additional cores, then the other threads will continue to run normally. If you're on a single core machine, then the other threads will never get a chance to run, ergo thay can't be killed. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
Hi All, Man page of waitpid give expansion with example on how to send SIGSTOP, SIGCONT and SIGKILL/SIGTERM to a running process. If we don't implement waitpid system call we will not be able to observer the states of process when we issue a signal to running process. -Anand Moon ________________________________ From: Mulyadi Santosa <mulyadi.santosa@gmail.com> To: Darshan Ghumare <darshan.ghumare@gmail.com> Cc: kernelnewbies <Kernelnewbies@kernelnewbies.org> Sent: Thursday, January 19, 2012 8:56 PM Subject: Re: SIGKILL Hi again :) On Thu, Jan 19, 2012 at 16:03, Darshan Ghumare <darshan.ghumare@gmail.com> wrote:
What if, there is one process which is in middle of a syscall which has infinite loop in it received SIGKILL & there are no other processes in the system?
infinite loop such as "for(;;)" ? well as long as it doesn't disable or masked out the timer interrupt, sooner or later timer interrupt will kick in. It then followed by the usual tick handler. Inside it, IIRC, will provoke the current running process to check queued signal and handle it. if the process then killed and no other process is running (are you sure? not even kernel threads?), then kernel will enter idle state. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (4)
-
Anand Moon -
Darshan Ghumare -
Dave Hylands -
Mulyadi Santosa