[GIT PULL] XFS update for 2.6.26-rc4 (revised)

[Lachlan McIlroy]

Please pull from the for-linus branch:
    git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus

This will update the following files:

 fs/xfs/linux-2.6/xfs_buf.c   |   24 ++++++++--
 fs/xfs/linux-2.6/xfs_buf.h   |   19 +++++++
 fs/xfs/linux-2.6/xfs_file.c  |   17 ++++--
 fs/xfs/linux-2.6/xfs_vnode.h |    8 ---
 fs/xfs/xfs_inode.c           |    9 ++--
 fs/xfs/xfs_vnodeops.c        |  112 ++++++++++++++++--------------------------
 fs/xfs/xfs_vnodeops.h        |    3 +-
 7 files changed, 98 insertions(+), 94 deletions(-)

through these commits:

commit 6ab455eeaff6893cd06da33843e840d888cdc04a
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Mon May 19 16:34:42 2008 +1000

    [XFS] Fix memory corruption with small buffer reads
    
    When we have multiple buffers in a single page for a blocksize == pagesize
    filesystem we might overwrite the page contents if two callers hit it
    shortly after each other. To prevent that we need to keep the page locked
    until I/O is completed and the page marked uptodate.
    
    Thanks to Eric Sandeen for triaging this bug and finding a reproducible
    testcase and Dave Chinner for additional advice.
    
    This should fix kernel.org bz #10421.
    
    Tested-by: Eric Sandeen <sandeen@xxxxxxxxxxx>
    
    SGI-PV: 981813
    SGI-Modid: xfs-linux-melb:xfs-kern:31173a
    
    Signed-off-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Lachlan McIlroy <lachlan@xxxxxxx>

commit c8f5f12e46f079a954d4f7163ba59dadee08ca26
Author: David Chinner <dgc@xxxxxxx>
Date:   Tue May 20 11:30:15 2008 +1000

    [XFS] Fix inode list allocation size in writeback.
    
    We only need to allocate space for the number of inodes in the cluster
    when writing back inodes, not every byte in the inode cluster. This
    reduces the amount of memory needing to be allocated to 256 bytes instead
    of 64k.
    
    SGI-PV: 981949
    SGI-Modid: xfs-linux-melb:xfs-kern:31182a
    
    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Lachlan McIlroy <lachlan@xxxxxxx>

commit 49383b0e98ad1f69ff4c816eb1961f703df12318
Author: David Chinner <dgc@xxxxxxx>
Date:   Mon May 19 16:29:34 2008 +1000

    [XFS] Don't allow memory reclaim to wait on the filesystem in inode
    writeback
    
    If we allow memory reclaim to wait on the pages under writeback in inode
    cluster writeback we could deadlock because we are currently holding the
    ILOCK on the initial writeback inode which is needed in data I/O
    completion to change the file size or do unwritten extent conversion
    before the pages are taken out of writeback state.
    
    SGI-PV: 981091
    SGI-Modid: xfs-linux-melb:xfs-kern:31015a
    
    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Lachlan McIlroy <lachlan@xxxxxxx>

commit 978b7237123d007b9fa983af6e0e2fa8f97f9934
Author: David Chinner <dgc@xxxxxxx>
Date:   Mon May 19 16:29:46 2008 +1000

    [XFS] Fix fsync() b0rkage.
    
    xfs_fsync() fails to wait for data I/O completion before checking if the
    inode is dirty or clean to decide whether to log the inode or not. This
    misses inode size updates when the data flushed by the fsync() is
    extending the file.
    
    Hence, like fdatasync(), we need to wait for I/o completion first, then
    check the inode for cleanliness. Doing so makes the behaviour of
    xfs_fsync() identical for fsync and fdatasync and we *always* use
    synchronous semantics if the inode is dirty. Therefore also kill the
    differences and remove the unused flags from the xfs_fsync function and
    callers.
    
    SGI-PV: 981296
    SGI-Modid: xfs-linux-melb:xfs-kern:31033a
    
    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Lachlan McIlroy <lachlan@xxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/