Linux filesystem development
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
To: Erez Zadok <ezk@cs.sunysb.edu>
Cc: Dustin Kirkland <kirkland@canonical.com>,
	Saumitra Bhanage <sbhanage@cs.sunysb.edu>,
	Andrew Morton <akpm@linux-foundation.org>,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] ecryptfs: remove unnecessary d_drop calls in ecryptfs_link
Date: Mon, 7 Dec 2009 16:32:05 -0600	[thread overview]
Message-ID: <20091207223204.GC9807@fedora-virt> (raw)
In-Reply-To: <200912062305.nB6N5UiG029402@agora.fsl.cs.sunysb.edu>

On Sun Dec 06, 2009 at 06:05:30PM -0500, Erez Zadok (ezk@cs.sunysb.edu) was quoted:
> Tyler/Dustin,
> 
> We found three unnecessary calls to d_drop inside ecryptfs_link().  They are
> called unconditionally whether ->link succeeds or not.  They are unnecessary
> because they often remove valid objects from the dcache, which forces these
> objects to be re-looked up the next time they're needed.  Presumably the
> user process which called link(2) is likely to use those newly created
> hardlinks right afterwards.  So removing them from the dcache hurts
> performance.
> 
> We've tested the following patch in ecryptfs by successfully hard-linking a
> few files, looking them up, deleting them, etc.  Nothing too intensive
> thou.n However, we don't have those d_drop calls in unionfs, and it's been
> working fine for years.  Moreover, we've tested with and without those three
> d_drop calls in our wrapfs "pass-through" stackable file system with the
> full ltp/racer/etc. suites and all's well.  Therefore, we're reasonably
> certain that this patch is good.  Bug discovered by Aseem Rastogi during
> code review.
> 
> Still, perhaps someone can recall some history and how come these d_drop
> calls showed up in ecryptfs_link()?

git blame points out commits 45ec4aba and ae56fb16, but you aren't the
first person to point out these seemingly pointless d_drop's.  I think
I'll go ahead and commit this to the next branch and give it plenty of
testing.

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6.git#next

> 
> Cheers,
> Erez.
> 
> ------------------------------------------------------------------------------
> 
> ecryptfs: remove unnecessary d_drop calls in wrapfs_link
> 
> Unnecessary because it would unhash perfectly valid dentries, causing them
> to have to be re-looked up the next time they're needed, which presumably is
> right after.
> 
> Signed-off-by: Aseem Rastogi <arastogi@cs.sunysb.edu>
> Signed-off-by: Shrikar archak <shrikar84@gmail.com>
> Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
> diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
> index 186d744..2dc0bdb 100644
> --- a/fs/ecryptfs/inode.c
> +++ b/fs/ecryptfs/inode.c
> @@ -463,9 +463,6 @@ out_lock:
>  	unlock_dir(lower_dir_dentry);
>  	dput(lower_new_dentry);
>  	dput(lower_old_dentry);
> -	d_drop(lower_old_dentry);
> -	d_drop(new_dentry);
> -	d_drop(old_dentry);
>  	return rc;
>  }
> 

      reply	other threads:[~2009-12-07 22:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-06 23:05 [PATCH] ecryptfs: remove unnecessary d_drop calls in ecryptfs_link Erez Zadok
2009-12-07 22:32 ` Tyler Hicks [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=20091207223204.GC9807@fedora-virt \
    --to=tyhicks@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ezk@cs.sunysb.edu \
    --cc=kirkland@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sbhanage@cs.sunysb.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox