[bug report] NFS and uninterruptable wait states

[Phillip Susi <psusi@cfl.rr.com>]

The other day I was trying to set up an NFS mount to my room mate's system, 
and ran into what I at least, call a bug.  When I tried to mount his NFS 
export, the mount command locked up, and would not die.  Not even a SIGKILL 
would do any good.  According to ps, the mount process was in the 'D' - 
uninterruptable wait state.  It also looked like the WCHAN was rpc_ 
something.  I think it was waiting for an rpc call to return in the D state, 
and it never did return.  The bug here is that it should NOT be waiting in 
the D state for something that could never happen.  For that matter, why 
should anything ever need to wait in an uninterruptable state?  Whenever you 
wait, you should expect the possibility of being interrupted, check for that 
when you wake up, and if you were, clean up and return so the signal can be 
processed.

Anyhow, about an hour later ( the mount process still stuck ) I figured out 
that the other machine was not running rpc.nfsd, though it was running 
rpc.mountd.  Once I started rpc.nfsd on the machine, the mount on my box 
finally returned ( and was terminated by the SIGKILL that I sent it an hour 
before ).

Could someone confirm that this is a bug, and explain why anything should 
ever need to wait in that state?