On Fri, 2 Aug 2013 16:30:23 +0200 Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > 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. > Ok, good point... That's a tricky situation. We're rejecting the mount there because we can't _currently_ reach the mountpoint from root. It could become reachable later though, at which point you could mount on there just fine... It almost sounds like it could use a new error code (EUNREACH?). Or, maybe you could repurpose ENOLINK? In any case, I'd be inclined not to worry about it and just go with -ENOENT there. If someone complains we could consider a new error for that case later. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
