From: Sage Weil <sage@newdream.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: viro@ZenIV.linux.org.uk, linux-fsdevel@vger.kernel.org,
jeffm@suse.com, jack@suse.cz, me@bobcopeland.com,
tyhicks@linux.vnet.ibm.com
Subject: Re: [PATCH 00/19] Do not dentry_unhash in VFS (v3)
Date: Fri, 27 May 2011 12:11:00 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.1105271204260.26006@cobra.newdream.net> (raw)
In-Reply-To: <20110527094631.GA6702@infradead.org>
Hi Christoph,
On Fri, 27 May 2011, Christoph Hellwig wrote:
> Sage,
>
> this series still leaves a lot of dentry_unhash callsites around,
> can you submit some more patches to clan up after it?
>
> - bfs, sysv, jffs2, jfs, logfs, nilfs2, ubifs and ufs are plain old
> unix filesystems and should not have a problem.
> - reiserfs is a bit special but really shouldn't need it, also it has
> a local copy of vfs_rmdir that needs the call removed as well.
> - udf also seems to have normal unix semantics
> - same for omfs
> - ecryptfs just passed down requests to the lower fs and thus almost
> certainly doesn't need it.
> - hfs and hfsplus don't care
> - hostsfs doesn't really either
>
> Cced some more maintainers. In the end each callsite of dentry_unhash
> really should have a comment why it's needed or at least why we're
> unsure about it.
I'm going through and looking at all the remaining callers now. I just
want to verify one thing with you to make sure my understanding is 100%
correct: as long as the file system isn't looking at whether the dentry is
hashed or unhashed after the dentry_unhash() call, that implies that there
are no issues with lingering directory references, right? Because a
racing lookup getting into the directory (which dentry_unhash would
prevent) isn't any different from a prior reference if the fs isn't
checking the hashed status.
If that's the case, it looks like ncpfs is the main one that needs it.
hpfs does something really weird when close to ENOSPC and needs it for
that, but doesn't appear to for rmdir and dir rename. autofs4 I'm scared
to touch. Everyone else (9p, affs, afs, coda, configfs, fat, fuse, and
minix) I think I can remove.
Does that mesh with your understanding?
Thanks!
sage
prev parent reply other threads:[~2011-05-27 19:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 20:06 [PATCH 00/19] Do not dentry_unhash in VFS (v3) Sage Weil
2011-05-24 20:06 ` [PATCH 01/19] vfs: dentry_unhash immediately prior to rmdir Sage Weil
2011-05-24 20:06 ` [PATCH 02/19] vfs: remove dget() from dentry_unhash() Sage Weil
2011-05-24 20:06 ` [PATCH 03/19] vfs: push dentry_unhash on rmdir into file systems Sage Weil
2011-05-24 20:06 ` [PATCH 04/19] vfs: push dentry_unhash on rename_dir " Sage Weil
2011-05-24 20:06 ` [PATCH 05/19] vfs: update dentry_unhash() comment Sage Weil
2011-05-24 20:06 ` [PATCH 06/19] libfs: drop unneeded dentry_unhash Sage Weil
2011-05-24 20:06 ` [PATCH 07/19] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems Sage Weil
2011-05-24 20:06 ` [PATCH 08/19] vfs: clean up vfs_rmdir Sage Weil
2011-05-24 20:06 ` [PATCH 09/19] vfs: clean up vfs_rename_dir Sage Weil
2011-05-24 20:06 ` [PATCH 10/19] vfs: clean up vfs_rename_other Sage Weil
2011-05-24 20:06 ` [PATCH 11/19] ceph: remove unnecessary dentry_unhash calls Sage Weil
2011-05-24 20:06 ` [PATCH 12/19] btrfs: remove unnecessary dentry_unhash in rmdir/rename_dir Sage Weil
2011-05-24 20:06 ` [PATCH 13/19] ext4: remove unnecessary dentry_unhash on rmdir/rename_dir Sage Weil
2011-05-24 20:06 ` [PATCH 14/19] ext3: " Sage Weil
2011-05-24 20:38 ` Jan Kara
2011-05-24 23:57 ` Sage Weil
2011-05-25 2:44 ` Yongqiang Yang
2011-05-25 3:44 ` Sage Weil
2011-05-24 20:06 ` [PATCH 15/19] ext2: " Sage Weil
[not found] ` <1306267582-5347-1-git-send-email-sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org>
2011-05-24 20:06 ` [PATCH 16/19] nfs: " Sage Weil
2011-05-24 20:06 ` Sage Weil
2011-05-24 20:06 ` [PATCH 17/19] exofs: " Sage Weil
2011-05-24 20:06 ` [PATCH 18/19] ocfs2: " Sage Weil
2011-05-24 20:06 ` [Ocfs2-devel] " Sage Weil
2011-05-24 20:06 ` [PATCH 19/19] cifs: " Sage Weil
2011-05-27 9:46 ` [PATCH 00/19] Do not dentry_unhash in VFS (v3) Christoph Hellwig
2011-05-27 14:15 ` Jan Kara
2011-05-27 19:11 ` Sage Weil [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=Pine.LNX.4.64.1105271204260.26006@cobra.newdream.net \
--to=sage@newdream.net \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jeffm@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=me@bobcopeland.com \
--cc=tyhicks@linux.vnet.ibm.com \
--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.