[lkml]   [2001]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Suggest TASK_KILLABLE state to overcome most D state trouble
> 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

> 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' <>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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