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-next>] [day] [month] [year] [list]
Message-Id: <1301522968-4382-1-git-send-email-sage@newdream.net>
Date:	Wed, 30 Mar 2011 15:09:21 -0700
From:	Sage Weil <sage@...dream.net>
To:	viro@...IV.linux.org.uk, linux-fsdevel@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, mszeredi@...e.cz,
	Sage Weil <sage@...dream.net>
Subject: [PATCH 0/7] Do not dentry_unhash() in VFS

Hi Al, everyone,

For the most part the VFS does not hash or unhash dentries outside of 
dcache pruning.  This is left to the file system namespace methods.  The 
only exception is on rmdir and directory rename, where we call 
dentry_unhash() for the benefit of a few file systems that can't handle 
lingering references to the empty and unlinked directory.

This patchset aims to clean this up by pushing the dentry_unhash calls 
into each fs where they can be safely removed on a per-fs basis.  We 
also take this opportunity to finally fix a longstanding bug in 
vfs_rename_dir() which rehashes new_dentry (Miklos' patch, see
        http://marc.info/?l=linux-fsdevel&m=121666695328987&w=2
        http://marc.info/?t=121580579500004&r=1&w=2
).

On a per-fs basis, the dentry_unhash calls can be replaced with 
shrink_dcache_parent (or dropped entirely) if it is safe to do so.  I 
expect that this is safe for most of them.

My hope is that this will move us closer to being able to introduce a 
->d_prune d_op.  Independent of that, however, I think this is a 
worthwhile dcache cleanup.

Thanks!
sage



Miklos Szeredi (1):
  vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems

Sage Weil (6):
  vfs: dentry_unhash immediately prior to rmdir
  vfs: remove dget() from dentry_unhash()
  vfs: push dentry_unhash on rmdir into file systems
  vfs: push dentry_unhash on rename_dir into file systems
  vfs: update dentry_unhash() comment
  libfs: drop unneeded dentry_unhash

 fs/9p/vfs_inode.c       |    4 ++++
 fs/affs/namei.c         |    5 +++++
 fs/afs/dir.c            |    5 +++++
 fs/autofs4/root.c       |    2 ++
 fs/bfs/dir.c            |    3 +++
 fs/btrfs/inode.c        |    5 +++++
 fs/ceph/dir.c           |    6 ++++++
 fs/cifs/inode.c         |    5 +++++
 fs/coda/dir.c           |    5 +++++
 fs/configfs/dir.c       |    2 ++
 fs/ecryptfs/inode.c     |    5 +++++
 fs/exofs/namei.c        |    5 +++++
 fs/ext2/namei.c         |    5 +++++
 fs/ext3/namei.c         |    5 +++++
 fs/ext4/namei.c         |    5 +++++
 fs/fat/namei_msdos.c    |    5 +++++
 fs/fat/namei_vfat.c     |    5 +++++
 fs/fuse/dir.c           |    6 ++++++
 fs/gfs2/ops_inode.c     |    5 +++++
 fs/hfs/dir.c            |    6 ++++++
 fs/hfsplus/dir.c        |    2 ++
 fs/hostfs/hostfs_kern.c |    5 +++++
 fs/hpfs/namei.c         |    9 ++++++---
 fs/jffs2/dir.c          |    5 +++++
 fs/jfs/namei.c          |    5 +++++
 fs/libfs.c              |    4 ++++
 fs/logfs/dir.c          |    5 +++++
 fs/minix/namei.c        |    5 +++++
 fs/namei.c              |   21 ++++++---------------
 fs/ncpfs/dir.c          |    5 +++++
 fs/nfs/dir.c            |    5 +++++
 fs/nilfs2/namei.c       |    5 +++++
 fs/ocfs2/namei.c        |    6 ++++++
 fs/omfs/dir.c           |    5 +++++
 fs/reiserfs/namei.c     |    5 +++++
 fs/reiserfs/xattr.c     |    1 -
 fs/sysv/namei.c         |    5 +++++
 fs/ubifs/dir.c          |    5 +++++
 fs/udf/namei.c          |    5 +++++
 fs/ufs/namei.c          |    5 +++++
 40 files changed, 188 insertions(+), 19 deletions(-)

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ