Can't kill hung remote CP copy

[Shane]

On 04/14/2012 04:11 PM, Alan Cox wrote:
>> Under what circumstance would killing a waiting process
>> be worse than a process that should have waited,
>> but terminated instead?
> When it leaves the system in an unstable state or where corruption could
> follow. Far better then to leave that process stuck unless things sort
> out.

    But, drivers can also be reset.  And resetting a driver should, in 
theory, reset the hardware.  So a system should never be left in an 
unstable state.  But, what if there are other requests pending of that 
same hardware?  The only alternative is to invalidate those requests and 
issue an I/O error.  But the app-handlers should catch these and deal 
with them reasonably.

   Then there's the question of what could require an infinite amount of 
time for a driver to return?  How long will a human wait?  I can't think 
of a request that isn't bounded by some physical time limit except for a 
requested sleep alarm.  And I can't think of a request that I'm willing 
to wait on for 3 days.  There really shouldn't be a "wait-forever" state 
because that just means "wait until the user powers me off".  I think 
all states should be bounded.  At least bounded from the standpoint of 
returning to user-level for further action (either re-invocation of the 
wait or exiting).  Let the app-layer determine what to do if the lower 
level can't do something - the app-layer is free to re-invoke the kernel 
request.

   Shane