lkml.org 
[lkml]   [2004]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: is killing zombies possible w/o a reboot?
Date
On Thursday 04 November 2004 01:33, Russell Miller wrote:
> On Wednesday 03 November 2004 17:03, Doug McNaught wrote:
>
> > It was already mentioned in this thread that the bookkeeping required
> > to clean up properly from such an abort would add a lot of overhead
> > and slow down the normal, non-buggy case.
> >
> I am going to continue pursuing this at the risk of making a bigger fool of
> myself than I already am, but I want to make sure that I understand the
> issues - and I did read the message you are referring to.
>
> I think what you are saying is that there is kind of a race condition here.
> When something is on the wait queue, it has to be followed through to
> completion. An interrupt could be received at any time, and if it's taken
> off of the wait queue prematurely, it'll crash the kernel, because the
> interrupt has no way of telling that.

The problem is in locking. You must not kill process while it is
in uninterruptible state because it is uninterruptible
for a reason - has taken semaphore, or get_cpu(), etc.
You do want it to do put_cpu(), right?

Processes must never get stuck in D, it's a kernel bug.

Find out how did process ended up in D state forever,
and fix it - that's what I'm trying to do
in these cases.
--
vda

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.310 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site