linux.git/fs/inode.c, branch v3.3-rc2

vfs: remove printk from set_nlink()

2012-01-17T21:39:47+00:00

Don't log a message for set_nlink(0).

Signed-off-by: Miklos Szeredi 
Signed-off-by: Al Viro

mm: account reaped page cache on inode cache pruning

2012-01-11T00:30:42+00:00

Inode cache pruning indirectly reclaims page-cache by invalidating mapping
pages.  Let's account them into reclaim-state to notice this progress in
memory reclaimer.

Signed-off-by: Konstantin Khlebnikov 
Cc: Dave Chinner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vfs: count unlinked inodes

2012-01-07T04:20:12+00:00

Add a new counter to the superblock that keeps track of unlinked but
not yet deleted inodes.

Do not WARN_ON if set_nlink is called with zero count, just do a
ratelimited printk.  This happens on xfs and probably other
filesystems after an unclean shutdown when the filesystem reads inodes
which already have zero i_nlink.  Reported by Christoph Hellwig.

Signed-off-by: Miklos Szeredi 
Tested-by: Toshiyuki Okajima 
Signed-off-by: Al Viro

switch inode_init_owner() to umode_t

2012-01-04T03:55:11+00:00

Signed-off-by: Al Viro

vfs: fix the stupidity with i_dentry in inode destructors

2012-01-04T03:52:40+00:00

Seeing that just about every destructor got that INIT_LIST_HEAD() copied into
it, there is no point whatsoever keeping this INIT_LIST_HEAD in inode_init_once();
the cost of taking it into inode_init_always() will be negligible for pipes
and sockets and negative for everything else.  Not to mention the removal of
boilerplate code from ->destroy_inode() instances...

Signed-off-by: Al Viro

vfs: mnt_drop_write_file()

2012-01-04T03:52:40+00:00

new helper (wrapper around mnt_drop_write()) to be used in pair with
mnt_want_write_file().

Signed-off-by: Al Viro

vfs: protect i_nlink

2011-11-02T11:53:43+00:00

Prevent direct modification of i_nlink by making it const and adding a
non-const __i_nlink alias.

Signed-off-by: Miklos Szeredi 
Tested-by: Toshiyuki Okajima 
Signed-off-by: Christoph Hellwig

vfs: fix spinning prevention in prune_icache_sb

2011-10-28T12:58:55+00:00

We need to move the inode to the end of the list to actually make the
spinning prevention explained in the comment above it work.  With a
plain list_move it will simply stay in place as we're always reclaiming
from the head of the list.

Signed-off-by: Christoph Hellwig

lockdep: Add helper function for dir vs file i_mutex annotation

2011-08-25T17:50:18+00:00

Purely in-memory filesystems do not use the inode hash as the dcache
tells us if an entry already exists.  As a result, they do not call
unlock_new_inode, and thus directory inodes do not get put into a
different lockdep class for i_sem.

We need the different lockdep classes, because the locking order for
i_mutex is different for directory inodes and regular inodes.  Directory
inodes can do "readdir()", which takes i_mutex *before* possibly taking
mm->mmap_sem (due to a page fault while copying the directory entry to
user space).

In contrast, regular inodes can be mmap'ed, which takes mm->mmap_sem
before accessing i_mutex.

The two cases can never happen for the same inode, so no real deadlock
can occur, but without the different lockdep classes, lockdep cannot
understand that.  As a result, if CONFIG_DEBUG_LOCK_ALLOC is set, this
can lead to false positives from lockdep like below:

    find/645 is trying to acquire lock:
     (&mm->mmap_sem){++++++}, at: [] might_fault+0x5c/0xac

    but task is already holding lock:
     (&sb->s_type->i_mutex_key#15){+.+.+.}, at: []
    vfs_readdir+0x5b/0xb4

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&sb->s_type->i_mutex_key#15){+.+.+.}:
          [] lock_acquire+0xbf/0x103
          [] __mutex_lock_common+0x4c/0x361
          [] mutex_lock_nested+0x40/0x45
          [] hugetlbfs_file_mmap+0x82/0x110
          [] mmap_region+0x258/0x432
          [] do_mmap_pgoff+0x2ac/0x306
          [] sys_mmap_pgoff+0x118/0x16a
          [] sys_mmap+0x22/0x24
          [] system_call_fastpath+0x16/0x1b

    -> #0 (&mm->mmap_sem){++++++}:
          [] __lock_acquire+0xa1a/0xcf7
          [] lock_acquire+0xbf/0x103
          [] might_fault+0x89/0xac
          [] filldir+0x6f/0xc7
          [] dcache_readdir+0x67/0x205
          [] vfs_readdir+0x7b/0xb4
          [] sys_getdents+0x7e/0xd1
          [] system_call_fastpath+0x16/0x1b

This patch moves the directory vs file lockdep annotation into a helper
function that can be called by in-memory filesystems and has hugetlbfs
call it.

Signed-off-by: Josh Boyer 
Acked-by: Peter Zijlstra 
Signed-off-by: Linus Torvalds

vfs: optimize inode cache access patterns

2011-08-07T05:53:23+00:00

The inode structure layout is largely random, and some of the vfs paths
really do care.  The path lookup in particular is already quite D$
intensive, and profiles show that accessing the 'inode->i_op->xyz'
fields is quite costly.

We already optimized the dcache to not unnecessarily load the d_op
structure for members that are often NULL using the DCACHE_OP_xyz bits
in dentry->d_flags, and this does something very similar for the inode
ops that are used during pathname lookup.

It also re-orders the fields so that the fields accessed by 'stat' are
together at the beginning of the inode structure, and roughly in the
order accessed.

The effect of this seems to be in the 1-2% range for an empty kernel
"make -j" run (which is fairly kernel-intensive, mostly in filename
lookup), so it's visible.  The numbers are fairly noisy, though, and
likely depend a lot on exact microarchitecture.  So there's more tuning
to be done.

Signed-off-by: Linus Torvalds