SIGKILL

[Dave Hylands]

Hi Darshan,

On Sat, Jan 21, 2012 at 7:31 PM, Darshan Ghumare
<darshan.ghumare at gmail.com> wrote:
> On Fri, Jan 20, 2012 at 12:32 PM, Dave Hylands <dhylands at gmail.com> wrote:
...snip...
>> On Thu, Jan 19, 2012 at 9:41 PM, Darshan Ghumare
>> <darshan.ghumare at 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