User: Password:
|
|
Subscribe / Log in / New account

TASK_KILLABLE

TASK_KILLABLE

Posted Jul 21, 2008 18:06 UTC (Mon) by mcortese (guest, #52099)
Parent article: TASK_KILLABLE

Is it really impossible to get rid of a process stuck in an UNINTERRUPTIBLE wait? What prevents the kernel from just removing it from any queue and freeing its allocated memory?


(Log in to post comments)

TASK_KILLABLE

Posted Jul 21, 2008 21:09 UTC (Mon) by nix (subscriber, #2304) [Link]

How can you tell what queues it's on? If it's holding a lock (which it 
generally is, or the sleep would be interruptible) it's probably doing 
that because some data structure protected by that lock is in an 
inconsistent state. That data structure may very well not be per-process. 
How do you clean it up?

(And the answer is not always 'discard it': it may hold an inode lock and 
the inode in question has dirty data associated with it. Discarding that 
would not be a good idea!)

I suspect that uninterruptible sleep will always be with us in *some* form 
(at least until every single data structure in the kernel, and every 
single code flow path, gains cleanup handlers: and we know from C++ 
exceptions just how very easy that is to make work right and how very easy 
it is to trap all code flow paths that may need cleanups of some kind. Oh, 
sorry, did I say 'easy'? That should be 'difficult'.)

TASK_KILLABLE

Posted Jul 24, 2008 17:49 UTC (Thu) by mcortese (guest, #52099) [Link]

If it's holding a lock (which it generally is, or the sleep would be interruptible) it's probably doing that because some data structure protected by that lock is in an inconsistent state.
...whereas a KILLABLE task, despite having data in inconsistent state and not knowing how to deal with most incoming signals (and in that being much like the UNINTERRUPTIBLE variety), despite all that, it still knows how to deal with just one type of signal, kill.

Are there a lot of such tasks out there? (irony not intended, I really want to understand how much this change can improve the kernel)

TASK_KILLABLE

Posted Jul 25, 2008 20:28 UTC (Fri) by nix (subscriber, #2304) [Link]

If it's in KILLABLE state, it *does* know how to deal with signals within 
the kernel, and its in-kernel state can be cleanly unwound. The reason 
that this doesn't propagate up to userspace as an EINTR is simply that 
there is in effect a Unix guarantee that filesystem operations cannot be 
interrupted, and the vast majority of userspace code relies on this 
guarantee and will malfunction if it starts getting EINTRs from tasks. 
(This is what the old 'intr' option did, and boy were the results messy.)

That's why it only responds to SIGKILL: because SIGKILL, by definition, 
doesn't get propagated to userspace, because the process's userspace 
component is killed by the SIGKILL.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds