From: Hao Lee <haolee.swjtu@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs: Eliminate a local variable to make the code more clear
Date: Wed, 9 Sep 2020 15:32:43 +0000 [thread overview]
Message-ID: <20200909153243.GA25215@haolee.github.io> (raw)
In-Reply-To: <87k0x39kkr.fsf@x220.int.ebiederm.org>
On Wed, Sep 09, 2020 at 07:54:44AM -0500, Eric W. Biederman wrote:
> Hao Lee <haolee.swjtu@gmail.com> writes:
>
> > On Tue, Sep 08, 2020 at 07:48:57PM +0100, Al Viro wrote:
> >> On Tue, Sep 08, 2020 at 01:06:56PM +0000, Hao Lee wrote:
> >> > ping
> >> >
> >> > On Wed, Jul 29, 2020 at 03:21:28PM +0000, Hao Lee wrote:
> >> > > The dentry local variable is introduced in 'commit 84d17192d2afd ("get
> >> > > rid of full-hash scan on detaching vfsmounts")' to reduce the length of
> >> > > some long statements for example
> >> > > mutex_lock(&path->dentry->d_inode->i_mutex). We have already used
> >> > > inode_lock(dentry->d_inode) to do the same thing now, and its length is
> >> > > acceptable. Furthermore, it seems not concise that assign path->dentry
> >> > > to local variable dentry in the statement before goto. So, this function
> >> > > would be more clear if we eliminate the local variable dentry.
> >>
> >> How does it make the function more clear? More specifically, what
> >> analysis of behaviour is simplified by that?
> >
> > When I first read this function, it takes me a few seconds to think
> > about if the local variable dentry is always equal to path->dentry and
> > want to know if it has special purpose. This local variable may confuse
> > other people too, so I think it would be better to eliminate it.
>
> I tend to have the opposite reaction. I read your patch and wonder
> why path->dentry needs to be reread what is changing path that I can not see.
> my back.
If I understand correctly, accessing path->dentry->d_inode needs one
more instruction than accessing dentry->d_inode, so the original code is
more efficient.
>
> Now for clarity it would probably help to do something like:
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index bae0e95b3713..430f3b4785e3 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2206,7 +2206,7 @@ static struct mountpoint *lock_mount(struct path *path)
> return mp;
> }
> namespace_unlock();
> - inode_unlock(path->dentry->d_inode);
> + inode_unlock(dentry->d_inode);
> path_put(path);
> path->mnt = mnt;
> dentry = path->dentry = dget(mnt->mnt_root);
>
>
> So at least the inode_lock and inode_unlock are properly paired.
>
> At first glance inode_unlock using path->dentry instead of dentry
> appears to be an oversight in 84d17192d2af ("get rid of full-hash scan
> on detaching vfsmounts").
I think I have understood why we use the local variable dentry. Thanks.
Regards,
Hao Lee
>
>
> Eric
prev parent reply other threads:[~2020-09-09 17:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 15:21 [PATCH] fs: Eliminate a local variable to make the code more clear Hao Lee
2020-08-14 6:01 ` Hao Lee
2020-09-08 13:06 ` Hao Lee
2020-09-08 18:48 ` Al Viro
2020-09-08 23:11 ` Hao Lee
2020-09-09 12:54 ` Eric W. Biederman
2020-09-09 15:32 ` Hao Lee [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200909153243.GA25215@haolee.github.io \
--to=haolee.swjtu@gmail.com \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.