Huge race in lockd for async lock requests?

[Rob Gardner <rob.gardner@hp.com>]

I've got a question about lockd in conjunction with a filesystem that 
provides its own (async) locking.

After nlmsvc_lock() calls vfs_lock_file(), it seems to be that we might 
get the async callback (nlmsvc_grant_deferred) at any time. What's to 
stop it from arriving before we even put the block on the nlm_block 
list? If this happens, then nlmsvc_grant_deferred() will print "grant 
for unknown block" and then we'll wait forever for a grant that will 
never come.

Seems like we ought to do nlmsvc_insert_block() before vfs_lock_file() 
at the very least; But this still leaves problems where the lock is 
granted via the callback while we're still in nlmsvc_lock(), and we 
ignore it and tell the client that the lock is blocked; Now they'll have 
to retry before getting the lock.

Any thoughts on this besides "give up on using lockd"?

Rob Gardner