On Fri, Aug 2, 2013 at 1:43 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > Ok, took me a couple of times to look over the code but I think I > understand the problem now... > > IIUC, then this patch should only ever cause this to return -ENOENT in > a situation similar to the one in Anand's reproducer, right? The > mountpoint-to-be was unlinked in another tree, and thus we found it to > be invalid in the tree that we're mounting in. If so, then the dentry > didn't exist at some point during the race window. Returning -ENOENT > seems reasonable to me in that situation. Yes, that's one part of it and ENOENT fits perfectly. The other part is when the subtree is moved on another host. Yes, NFS can reconnect it, but only if it is accessed through the new location. Until then it will be inaccessible and the new location of the mountpoint not discoverable through /proc/mounts or in any way without outside knowledge. And there was a pre-existing mount under the moved directory we don't allow the d_drop in this "move" case either, and the mount is accessible through the old name. I seem to recall that there was a discussion about this back then and Linus was quite adamant about mountpoints not being allowed to be dissolved or moved without an explicit action on the localhost (i.e. something that happens on remote hosts shouldn't affect the status or location of mounts on the localhost). So what happens in this case: host1: cd /nfs/foo/bar host2: mv /nfs/foo /nfs/old-foo host2: mkdir /nfs/foo host1: ls /nfs/foo [drops "old-foo" and adds a new foo dentry] host1: mkdir bin [cwd is now not accessible from root] host1: mount --bind /bin ./bin [???] Currently that last one succeeds, with my patch it gives ENOENT, but that's not the best error, since the mountpoint does exist. Thanks, Miklos -- 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
