On Sat, Apr 16, 2016 at 01:55:19AM +0100, Al Viro wrote:
> From: Al Viro <v...@zeniv.linux.org.uk>
> 
> ... and explain the non-obvious logics in case when lookup yields
> a different dentry.

ACK to this independent of the rest of the series, my only minor gripe
is that the point made in this new comment is also made at
out_reconnected: and at the head of reconnect_one().  And would also
apply at the other "goto out_reconnected".  My preference is to leave
things as they are, but if you found it easy to overlook maybe just
something like:

 -              goto out_reconnected;
 +              goto out_reconnected; /* see comment there*/

would be helpful.  And/or improving the final comment.

--b.

> 
> Signed-off-by: Al Viro <v...@zeniv.linux.org.uk>
> ---
>  fs/exportfs/expfs.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
> index c46f1a1..402c5ca 100644
> --- a/fs/exportfs/expfs.c
> +++ b/fs/exportfs/expfs.c
> @@ -143,14 +143,18 @@ static struct dentry *reconnect_one(struct vfsmount 
> *mnt,
>       if (err)
>               goto out_err;
>       dprintk("%s: found name: %s\n", __func__, nbuf);
> -     inode_lock(parent->d_inode);
> -     tmp = lookup_one_len(nbuf, parent, strlen(nbuf));
> -     inode_unlock(parent->d_inode);
> +     tmp = lookup_one_len_unlocked(nbuf, parent, strlen(nbuf));
>       if (IS_ERR(tmp)) {
>               dprintk("%s: lookup failed: %d\n", __func__, PTR_ERR(tmp));
>               goto out_err;
>       }
>       if (tmp != dentry) {
> +             /*
> +              * Somebody has renamed it since exportfs_get_name();
> +              * great, since it could've only been renamed if it
> +              * got looked up and thus connected, and it would
> +              * remain connected afterwards.  We are done.
> +              */
>               dput(tmp);
>               goto out_reconnected;
>       }
> -- 
> 2.8.0.rc3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to