SIGKILL

SIGKILL

[Mulyadi Santosa]

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

SIGKILL

[Darshan Ghumare]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120119/a16e93b5/attachment.html 

SIGKILL

[Mulyadi Santosa]

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

SIGKILL

[Dave Hylands]

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

SIGKILL

[Anand Moon]

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 at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120119/fbd23b47/attachment.html 

SIGKILL

[Darshan Ghumare]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120120/c0b0f0a6/attachment.html 

SIGKILL

[Dave Hylands]

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

SIGKILL

[Darshan Ghumare]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120122/365ce535/attachment.html 

SIGKILL

[Dave Hylands]

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