On Thu, Jan 19, 2012 at 10:54 PM, Dave Hylands <dhylands@xxxxxxxxx> wrote:
Hi,
On Thu, Jan 19, 2012 at 7:26 AM, Mulyadi SantosaIf the process was in an infinite loop in user space, what Mulyadi
<mulyadi.santosa@xxxxxxxxx> wrote:
> Hi again :)
>
> On Thu, Jan 19, 2012 at 16:03, Darshan Ghumare
> <darshan.ghumare@xxxxxxxxx> 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.
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®
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
