linux/fs/exportfs, branch v3.13

exportfs: fix quadratic behavior in filehandle lookup

2013-11-09T05:16:38Z

Suppose we're given the filehandle for a directory whose closest ancestor in the dcache is its Nth ancestor. The main loop in reconnect_path searches for an IS_ROOT ancestor of target_dir, reconnects that ancestor to its parent, then recommences the search for an IS_ROOT ancestor from target_dir. This behavior is quadratic in N. And there's really no need to restart the search from target_dir each time: once a directory has been looked up, it won't become IS_ROOT again. So instead of starting from target_dir each time, we can continue where we left off. This simplifies the code and improves performance on very deep directory heirachies. (I can't think of any reason anyone should need heirarchies a hundred or more deep, but the performance improvement may be valuable if only to limit damage in case of abuse.) Reviewed-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: better variable name

2013-11-09T05:16:38Z

Replace another unhelpful acronym. Reviewed-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: move most of reconnect_path to helper function

2013-11-09T05:16:37Z

Also replace 3 easily-confused three-letter acronyms by more helpful variable names. Just cleanup, no change in functionality, with one exception: the dentry_connected() check in the "out_reconnected" case will now only check the ancestors of the current dentry instead of checking all the way from target_dir. Since we've already verified connectivity up to this dentry, that should be sufficient. Reviewed-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: eliminate unused "noprogress" counter

2013-11-09T05:16:37Z

Note this counter is now being set to 0 on every pass through the loop, so it no longer serves any useful purpose. Reviewed-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: stop retrying once we race with rename/remove

2013-11-09T05:16:36Z

There are two places here where we could race with a rename or remove: - We could find the parent, but then be removed or renamed away from that parent directory before finding our name in that directory. - We could find the parent, and find our name in that parent, but then be renamed or removed before we look ourselves up by that name in that parent. In both cases the concurrent rename or remove will take care of reconnecting the directory that we're currently examining. Our target directory should then also be connected. Check this and clear DISCONNECTED in these cases instead of looping around again. Note: we *do* need to check that this actually happened if we want to be robust in the face of corrupted filesystems: a corrupted filesystem could just return a completely wrong parent, and we want to fail with an error in that case before starting to clear DISCONNECTED on non-DISCONNECTED filesystems. Reviewed-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: clear DISCONNECTED on all parents sooner

2013-11-09T05:16:36Z

Once we've found any connected parent, we know all our parents are connected--that's true even if there's a concurrent rename. May as well clear them all at once and be done with it. Reviewed-by: Cristoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: more detailed comment for path_reconnect

2013-11-09T05:16:35Z

Reviewed-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: BUG_ON in crazy corner case

2013-11-09T05:16:35Z

This would indicate a nasty bug in the dcache and has never triggered in the past 10 years as far as I know. Reviewed-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: fix 32-bit nfsd handling of 64-bit inode numbers

2013-11-09T05:16:32Z

Symptoms were spurious -ENOENTs on stat of an NFS filesystem from a 32-bit NFS server exporting a very large XFS filesystem, when the server's cache is cold (so the inodes in question are not in cache). Reviewed-by: Christoph Hellwig Reported-by: Trevor Cordes Signed-off-by: J. Bruce Fields Signed-off-by: Al Viro

exportfs: don't assume that ->iterate() won't feed us too long entries

2013-09-07T23:54:55Z

On some filesystems it's impossible even with fs corruption, but we'd better not rely on that, what with memcpy() into on-stack array we are doing there. Signed-off-by: Al Viro