SIGKILL

[Darshan Ghumare]

On Thu, Jan 19, 2012 at 10:54 PM, Dave Hylands <dhylands at gmail.com> wrote:

> Hi,
> On Thu, Jan 19, 2012 at 7:26 AM, Mulyadi Santosa
> <mulyadi.santosa at gmail.com> wrote:
> > Hi again :)
> >
> > On Thu, Jan 19, 2012 at 16:03, Darshan Ghumare
> > <darshan.ghumare at 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