[PATCH] exportfs: fix handling of rename race in reconnect_one()

[Amir Goldstein <amir73il@gmail.com>]

If a disconnected dentry gets looked up and renamed between the
call to exportfs_get_name() and lookup_one_len_unlocked(), and if also
lookup_one_len_unlocked() returns ERR_PTR(-ENOENT), maybe because old
parent was deleted, we return an error, although dentry may be connected.

Commit 909e22e05353 ("exportfs: fix 'passing zero to ERR_PTR()'
warning") changes this behavior from always returning success,
regardless if dentry was reconnected by somoe other task, to always
returning a failure.

Change the lookup error handling to match that of exportfs_get_name()
error handling and return success after getting -ENOENT and verifying
that some other task has connected the dentry for us.

Cc: Christoph Hellwig <hch@lst.de>
Cc: J. Bruce Fields <bfields@redhat.com>
Fixes: 909e22e05353 ("exportfs: fix 'passing zero to ERR_PTR()' warning")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 fs/exportfs/expfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
index 2dd55b172d57..25a09bacf9c1 100644
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -149,6 +149,8 @@ static struct dentry *reconnect_one(struct vfsmount *mnt,
 	if (IS_ERR(tmp)) {
 		dprintk("%s: lookup failed: %d\n", __func__, PTR_ERR(tmp));
 		err = PTR_ERR(tmp);
+		if (err == -ENOENT)
+			goto out_reconnected;
 		goto out_err;
 	}
 	if (tmp != dentry) {
-- 
2.17.1