"Chuck Lever" <chuck.lever@xxxxxxxxxx> writes: > That makes sense. > > This is likely coming from lockd_down(), and is almost certainly not > coming from the same uts namespace as the lockd_up() that did the > pmap_set, which was done by the first NFS mount done in the first uts > namespace on the system. It's just something that the kernel has to > do for maintenance. > > There is only one lockd() instance that is shared among all the uts > namespaces, right? In this case, what is the correct utsname to use? Interesting. As a general rule I would say we should capture the uts instance in locked_up(). And use the same instance in locked_down(). I'm not at all familiar with how locked interacts with nfs mounts in a practical sense. Is there one locked instance (or at least context) per nfs mount? The way I would expect things to work is that when we mount an nfs filesystem from an nfs server. We would create a locked context for that server, that additional nfs mounts to the same nfs server could share. The way I would expect nfs to interact with the namespaces is for the nfs mount to capture the uts and network namespaces, and use them for all transactions relating to the mount. In particular when creating or a locked context the nfs mount would use the uts namespace and the network namespace as discriminators to see if an existing locked context is the same. I don't think nfs has a 1-1 thread to context model which is where things get really hazy for me. The conservative play is to always force use of the initial namespace and to deny creation of mounts that would use different namespaces. In part because the initial version of the namespace always exists. Which means as relates to Cedrics initial patch we would still need to know which mounts should cause us to use a different uts namespace so we can deny them. Eric -- 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
