Messages in this thread |  | | Date | Mon, 1 Oct 2001 13:32:15 +0200 | From | Jan Hudec <> | Subject | Re: Suggest TASK_KILLABLE state to overcome most D state trouble |
| |
> bulb@ucw.cz said: > > Does a patch adding a TASK_KILLABLE state have a chance to get in (in > > 2.5)? Or can anybody thik of more elegant solution? > Often there's kernel state which needs to be kept consistent, and locks > which need to be released - just bailing out (as if you got an oops) isn't > sufficient.
No. It's not sufficient. It won't be sufficient even with KILLABLE state. But the difference between SIGKILL and other signals is, that when you get SIGKILL, you know, what's going to happen. With other signals, you don't.
> What's wrong with the plan of just implementing the appropriate cleanup code > in each buggy or lazy piece of code which sleeps in state > TASK_UNINTERRUPTIBLE, and letting each be interruptible instead?
There are many situations, that could be interupted with sigkill (you sent a request, then die from sigkill, so you know the reply won't matter), while it's difficult to restart after signal, because you already started a request and if you just started it again, the reply won't be the same. So it's not about cleanup. But you need to maintain some state to pass to the restarted syscall. And it's impossible with current signal handling mechanism (the problem is garbage-collecting the state).
Little different problem is the page-fault, that could immediately occur again if signal handler was invoked, but on sigkill no handler is run, so you may safely abort.
-------------------------------------------------------------------------------- - Jan Hudec `Bulb' <bulb@ucw.cz> - 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/
|  |