[XFS updates] XFS development tree branch, for-next, updated. v3.2-rc1-11478-gf074211

[xfs at oss.sgi.com]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-next has been updated
  f074211 xfs: fallback to vmalloc for large buffers in xfs_getbmap
  ad650f5 xfs: fallback to vmalloc for large buffers in xfs_attrmulti_attr_get
  6eb2466 xfs: remove remaining scraps of struct xfs_iomap
  f30d500 xfs: fix inode lookup race
  8d2a5e6 xfs: clean up minor sparse warnings
      from  a05931ceb0160deadbd7798d60d01b17f2d81b09 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit f074211f6041305b645669464343d504f4e6a290
Author: Dave Chinner <dchinner at redhat.com>
Date:   Wed Mar 7 04:50:22 2012 +0000

    xfs: fallback to vmalloc for large buffers in xfs_getbmap
    
    xfs_getbmap uses for a large buffer for extents, which is kmalloc'd.
    This can fail after the system has been running for some time as it
    is a high order allocation. Add a fallback to vmalloc so that it
    doesn't require contiguous memory and so won't randomly fail on
    files with large extent lists.
    
    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Christoph Hellwig <hch at lst.de>
    Reviewed-by: Mark Tinguely <tinguely at sgi.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

commit ad650f5b27bc9858360b42aaa0d9204d16115316
Author: Dave Chinner <dchinner at redhat.com>
Date:   Wed Mar 7 04:50:21 2012 +0000

    xfs: fallback to vmalloc for large buffers in xfs_attrmulti_attr_get
    
    xfsdump uses for a large buffer for extended attributes, which has a
    kmalloc'd shadow buffer in the kernel. This can fail after the
    system has been running for some time as it is a high order
    allocation. Add a fallback to vmalloc so that it doesn't require
    contiguous memory and so won't randomly fail while xfsdump is
    running.
    
    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Christoph Hellwig <hch at lst.de>
    Reviewed-by: Mark Tinguely <tinguely at sgi.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

commit 6eb2466036358078aed9a65d702cbc97baf0ce65
Author: Dave Chinner <dchinner at redhat.com>
Date:   Wed Mar 7 04:50:24 2012 +0000

    xfs: remove remaining scraps of struct xfs_iomap
    
    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Christoph Hellwig <hch at lst.de>
    Reviewed-by: Mark Tinguely <tinguely at sgi.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

commit f30d500f809eca67a21704347ab14bb35877b5ee
Author: Dave Chinner <dchinner at redhat.com>
Date:   Wed Mar 7 04:50:25 2012 +0000

    xfs: fix inode lookup race
    
    When we get concurrent lookups of the same inode that is not in the
    per-AG inode cache, there is a race condition that triggers warnings
    in unlock_new_inode() indicating that we are initialising an inode
    that isn't in a the correct state for a new inode.
    
    When we do an inode lookup via a file handle or a bulkstat, we don't
    serialise lookups at a higher level through the dentry cache (i.e.
    pathless lookup), and so we can get concurrent lookups of the same
    inode.
    
    The race condition is between the insertion of the inode into the
    cache in the case of a cache miss and a concurrently lookup:
    
    Thread 1			Thread 2
    xfs_iget()
      xfs_iget_cache_miss()
        xfs_iread()
        lock radix tree
        radix_tree_insert()
    				rcu_read_lock
    				radix_tree_lookup
    				lock inode flags
    				XFS_INEW not set
    				igrab()
    				unlock inode flags
    				rcu_read_unlock
    				use uninitialised inode
    				.....
        lock inode flags
        set XFS_INEW
        unlock inode flags
        unlock radix tree
      xfs_setup_inode()
        inode flags = I_NEW
        unlock_new_inode()
          WARNING as inode flags != I_NEW
    
    This can lead to inode corruption, inode list corruption, etc, and
    is generally a bad thing to occur.
    
    Fix this by setting XFS_INEW before inserting the inode into the
    radix tree. This will ensure any concurrent lookup will find the new
    inode with XFS_INEW set and that forces the lookup to wait until the
    XFS_INEW flag is removed before allowing the lookup to succeed.
    
    cc: <stable at vger.kernel.org> # for 3.0.x, 3.2.x
    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Christoph Hellwig <hch at lst.de>
    Signed-off-by: Ben Myers <bpm at sgi.com>

commit 8d2a5e6ee37f205b3d76c223d4f3f88ba1d06220
Author: Dave Chinner <dchinner at redhat.com>
Date:   Wed Mar 7 04:50:19 2012 +0000

    xfs: clean up minor sparse warnings
    
    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Christoph Hellwig <hch at lst.de>
    Signed-off-by: Ben Myers <bpm at sgi.com>

-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/xfs_bmap.c       |   13 ++++++++++---
 fs/xfs/xfs_dir2_block.c |    1 +
 fs/xfs/xfs_iget.c       |   18 ++++++++++++------
 fs/xfs/xfs_ioctl.c      |   14 ++++++++++----
 fs/xfs/xfs_ioctl32.c    |    2 +-
 fs/xfs/xfs_iops.c       |   13 ++++++++-----
 fs/xfs/xfs_vnode.h      |    1 -
 fs/xfs/xfs_vnodeops.h   |    3 ---
 8 files changed, 42 insertions(+), 23 deletions(-)


hooks/post-receive
-- 
XFS development tree