Re: Huge race in lockd for async lock requests?

[Tom Talpey <tmtalpey@gmail.com>]

At 04:43 PM 5/19/2009, Rob Gardner wrote:
>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.

Yes, there's a race but the client will retry every 30 seconds, so it won't
wait forever. Depending on the kernel client version, there are some
improvements we've tried over time to close the raciness a little. What
exact client version are you working with?

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

It's a little worse than that. It's also possible for the client to hold a lock,
but a stray or retried server callback can cause the client to reject it,
releasing the lock at the server. This causes the server to grant the lock
to another client even though the first client still thinks it holds it. It's an
NLM protocol issue, frankly, due to the fact that the server callback is a
completely separate channel.

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

Use NFSv4? ;-)

Tom.

>
>Rob Gardner
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>