linux-kernel - Re: [PATCH 4/7] vfs: push dentry_unhash on rename

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 30 Mar 2011 21:40:15 -0700 (PDT)
From:	Sage Weil <sage@...dream.net>
To:	Dave Chinner <david@...morbit.com>
cc:	viro@...IV.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, mszeredi@...e.cz
Subject: Re: [PATCH 4/7] vfs: push dentry_unhash on rename_dir into file
 systems

On Thu, 31 Mar 2011, Dave Chinner wrote:
> On Wed, Mar 30, 2011 at 03:09:25PM -0700, Sage Weil wrote:
> > Only a few file systems need this.  Start by pushing it down into each
> > rename method so that it can be dealt with on a per-fs basis.
> 
> What is the criteria for a filesystem needing this?

As I understand it, it's normally just a question of whether the FS can 
handle references to the directory's struct inode and dentry after they've 
been unlinked.  A few file systems bail out of rmdir/rename if 
!d_unhashed(dentry) (dentry_unhash() doesn't unhash if there are any other 
dentry references).

All but a handful of file systems should be able to drop the dentry_unhash 
entirely.

> > Signed-off-by: Sage Weil <sage@...dream.net>
> > ---
> >  fs/9p/vfs_inode.c       |    3 +++
> >  fs/affs/namei.c         |    3 +++
> >  fs/afs/dir.c            |    3 +++
> >  fs/bfs/dir.c            |    3 +++
> >  fs/btrfs/inode.c        |    3 +++
> >  fs/ceph/dir.c           |    3 +++
> >  fs/cifs/inode.c         |    3 +++
> >  fs/coda/dir.c           |    3 +++
> >  fs/ecryptfs/inode.c     |    3 +++
> >  fs/exofs/namei.c        |    3 +++
> >  fs/ext2/namei.c         |    3 +++
> >  fs/ext3/namei.c         |    3 +++
> >  fs/ext4/namei.c         |    3 +++
> >  fs/fat/namei_msdos.c    |    3 +++
> >  fs/fat/namei_vfat.c     |    3 +++
> >  fs/fuse/dir.c           |    4 ++++
> >  fs/gfs2/ops_inode.c     |    3 +++
> >  fs/hfs/dir.c            |    3 +++
> >  fs/hostfs/hostfs_kern.c |    3 +++
> >  fs/hpfs/namei.c         |    4 ++++
> >  fs/jffs2/dir.c          |    3 +++
> >  fs/jfs/namei.c          |    3 +++
> >  fs/libfs.c              |    3 +++
> >  fs/logfs/dir.c          |    3 +++
> >  fs/minix/namei.c        |    3 +++
> >  fs/namei.c              |    5 +----
> >  fs/ncpfs/dir.c          |    3 +++
> >  fs/nfs/dir.c            |    3 +++
> >  fs/nilfs2/namei.c       |    3 +++
> >  fs/ocfs2/namei.c        |    3 +++
> >  fs/omfs/dir.c           |    3 +++
> >  fs/reiserfs/namei.c     |    3 +++
> >  fs/sysv/namei.c         |    3 +++
> >  fs/ubifs/dir.c          |    3 +++
> >  fs/udf/namei.c          |    3 +++
> >  fs/ufs/namei.c          |    3 +++
> >  36 files changed, 108 insertions(+), 4 deletions(-)
> 
> You didn't push it down into XFS, hence my question....

Whoops... I was grepping for .rmdir and .rename in fs/*.c.  I'll fix it 
up.

sage
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/