On Thu, 2009-02-12 at 16:36 +0100, Frank van Maarseveen wrote: > A little theorizing: > If the unlock of a yet unrecovered lock has failed up to that point then > the client sure must remember the lock somehow. That might explain the > secondary error when a conflicting lock is granted by the server. Sorry, but that doesn't hold water. The client will release the VFS 'mirror' of the lock before it attempts to unlock. Otherwise, you could have some nasty races between the unlock thread and the recovery thread... Besides, the granted callback handler on the client only checks the list of blocked locks for a match. Oh, bugger, I know what this is... It's the same thing that happened to the NFSv4 callback server. If you compile with CONFIG_IPV6 or CONFIG_IPV6_MODULE enabled, and also set CONFIG_SUNRPC_REGISTER_V4, then the NLM server will listen on an IPv6 socket, and so the RPC request come in with their IPv4 address mapped into the IPv6 namespace. The client, on the other hand, is using an IPv4 socket, 'cos you specified an IPv4 address to the mount command. The result is that the call to nlm_cmp_addr() in nlmclnt_grant() always fails... Basically, we need to replace nlm_cmp_addr() with something akin to nfs_sockaddr_match_ipaddr(), which will compare v4 mapped addresses. The workaround should be simply to turn off CONFIG_SUNRPC_REGISTER_V4 if you're not planning on ever using NFS-over-IPv6... Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
