I was testing NLM failover patches this morning and found the command 
hangs. Look like nlm_traverse_files(), where it grabs nlm_file_mutex 
early in the call, will have a chance to call nlm_release_file() via 
nlmsvc_free_block() inside kref_put(). The nlm_release_file() wants 
nlm_file_mutex too - this would generate a deadlock as the following:

dhcp59-234 kernel: Call Trace:
[<c02dd749>] __mutex_lock_slowpath+0x4c/0x7e
[<c02dd78a>] .text.lock.mutex+0xf/0x14
[<f8afeacd>] nlm_release_file+0x2b/0xdf [lockd]
[<f8afda90>] nlmsvc_free_block+0x8c/0x9d [lockd]
[<f8afda04>] nlmsvc_free_block+0x0/0x9d [lockd]
[<c01be98d>] kref_put+0x4e/0x58
[<f8afd175>] nlmsvc_traverse_blocks+0xaf/0xc6 [lockd]
[<f8afe960>] nlm_traverse_files+0x108/0x1cd [lockd]

The attached patch seems to fix the issue - it skips (defers) the file 
removal. Eventually either nlm_gc_hosts (some time later when client is 
unmonitored) or nlmsvc_traverse_files will finish the clean up.  Note 
that this is a 10-minutes  work - not sure its ramification at this 
moment. Take a look ?

-- Wendy