Suggest TASK_KILLABLE state to overcome most D state trouble

Suggest TASK_KILLABLE state to overcome most D state trouble

[Jan Hudec]

Hello,

I am develpoing a network filesystem and I come across the problem with
noninteruptible waiting (the same as with NFS). Unfortunately there are
some cases, where waiting interuptibly and returning ERESTARTSYS is
difficult to imposible to do (when upcall is done, it must be remembered,
for the restarted syscall, but the syscall may not get restarted).

I can see 2 ways out for most cases.

The simpler one: add a TASK_KILLABLE state, that would be between INTERUPTIBLE
and NONINTERUPTIBLE. It could be interupted only with SIGKILL (I first thought
SIGSTOP too but that one shouldn't matter). In that case the syscall knows
it's canceled. I think most waiting in D state can be changed to be killable.
Mainly when handling page-fault (which may wait on network, that is even
indefinitely in case of failure). It won't make the system behave very nicely
in case of network failure, but would at least allow killing locked processes.

The more complicated would be to change the signal handling to allow hook
to be called when the syscall won't be restarted so the driver could
get rid of now invalid state information.

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?

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>

Re: Suggest TASK_KILLABLE state to overcome most D state trouble

[David Woodhouse]

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.

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?

--
dwmw2

Re: Suggest TASK_KILLABLE state to overcome most D state trouble

[Jan Hudec]

> 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>