[XFS updates] XFS development tree branch, for-next, updated. v3.8-rc1-18-gced55f3

Sat Jan 26 09:44:44 CST 2013

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
  ced55f3 xfs: Fix possible use-after-free with AIO
  3b19034 xfs: fix shutdown hang on invalid inode during create
  4d559a3 xfs: limit speculative prealloc near ENOSPC thresholds
  10616b8 xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
      from  003fd6c8be14a348c56cb1d171605ab13fca906f (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 ced55f38d6bde7c10a14ea51c2edcd51a98575e3
Author: Jan Kara <jack at suse.cz>
Date:   Wed Jan 23 13:56:18 2013 +0100

    xfs: Fix possible use-after-free with AIO

    Running AIO is pinning inode in memory using file reference. Once AIO
    is completed using aio_complete(), file reference is put and inode can
    be freed from memory. So we have to be sure that calling aio_complete()
    is the last thing we do with the inode.

    CC: xfs at oss.sgi.com
    CC: Ben Myers <bpm at sgi.com>
    CC: stable at vger.kernel.org
    Signed-off-by: Jan Kara <jack at suse.cz>
    Reviewed-by: Ben Myers <bpm at sgi.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

commit 3b19034d4f4554e39ca244fb28962bbf2ccba046
Author: Dave Chinner <dchinner at redhat.com>
Date:   Mon Jan 21 23:53:55 2013 +1100

    xfs: fix shutdown hang on invalid inode during create

    When the new inode verify in xfs_iread() fails, the create
    transaction is aborted and a shutdown occurs. The subsequent unmount
    then hangs in xfs_wait_buftarg() on a buffer that has an elevated
    hold count. Debug showed that it was an AGI buffer getting stuck:

    [   22.576147] XFS (vdb): buffer 0x2/0x1, hold 0x2 stuck
    [   22.976213] XFS (vdb): buffer 0x2/0x1, hold 0x2 stuck
    [   23.376206] XFS (vdb): buffer 0x2/0x1, hold 0x2 stuck
    [   23.776325] XFS (vdb): buffer 0x2/0x1, hold 0x2 stuck

    The trace of this buffer leading up to the shutdown (trimmed for
    brevity) looks like:

    xfs_buf_init:        bno 0x2 nblks 0x1 hold 1 caller xfs_buf_get_map
    xfs_buf_get:         bno 0x2 len 0x200 hold 1 caller xfs_buf_read_map
    xfs_buf_read:        bno 0x2 len 0x200 hold 1 caller xfs_trans_read_buf_map
    xfs_buf_iorequest:   bno 0x2 nblks 0x1 hold 1 caller _xfs_buf_read
    xfs_buf_hold:        bno 0x2 nblks 0x1 hold 1 caller xfs_buf_iorequest
    xfs_buf_rele:        bno 0x2 nblks 0x1 hold 2 caller xfs_buf_iorequest
    xfs_buf_iowait:      bno 0x2 nblks 0x1 hold 1 caller _xfs_buf_read
    xfs_buf_ioerror:     bno 0x2 len 0x200 hold 1 caller xfs_buf_bio_end_io
    xfs_buf_iodone:      bno 0x2 nblks 0x1 hold 1 caller _xfs_buf_ioend
    xfs_buf_iowait_done: bno 0x2 nblks 0x1 hold 1 caller _xfs_buf_read
    xfs_buf_hold:        bno 0x2 nblks 0x1 hold 1 caller xfs_buf_item_init
    xfs_trans_read_buf:  bno 0x2 len 0x200 hold 2 recur 0 refcount 1
    xfs_trans_brelse:    bno 0x2 len 0x200 hold 2 recur 0 refcount 1
    xfs_buf_item_relse:  bno 0x2 nblks 0x1 hold 2 caller xfs_trans_brelse
    xfs_buf_rele:        bno 0x2 nblks 0x1 hold 2 caller xfs_buf_item_relse
    xfs_buf_unlock:      bno 0x2 nblks 0x1 hold 1 caller xfs_trans_brelse
    xfs_buf_rele:        bno 0x2 nblks 0x1 hold 1 caller xfs_trans_brelse
    xfs_buf_trylock:     bno 0x2 nblks 0x1 hold 2 caller _xfs_buf_find
    xfs_buf_find:        bno 0x2 len 0x200 hold 2 caller xfs_buf_get_map
    xfs_buf_get:         bno 0x2 len 0x200 hold 2 caller xfs_buf_read_map
    xfs_buf_read:        bno 0x2 len 0x200 hold 2 caller xfs_trans_read_buf_map
    xfs_buf_hold:        bno 0x2 nblks 0x1 hold 2 caller xfs_buf_item_init
    xfs_trans_read_buf:  bno 0x2 len 0x200 hold 3 recur 0 refcount 1
    xfs_trans_log_buf:   bno 0x2 len 0x200 hold 3 recur 0 refcount 1
    xfs_buf_item_unlock: bno 0x2 len 0x200 hold 3 flags DIRTY liflags ABORTED
    xfs_buf_unlock:      bno 0x2 nblks 0x1 hold 3 caller xfs_buf_item_unlock
    xfs_buf_rele:        bno 0x2 nblks 0x1 hold 3 caller xfs_buf_item_unlock

    And that is the AGI buffer from cold cache read into memory to
    transaction abort. You can see at transaction abort the bli is dirty
    and only has a single reference. The item is not pinned, and it's
    not in the AIL. Hence the only reference to it is this transaction.

    The problem is that the xfs_buf_item_unlock() call is dropping the
    last reference to the xfs_buf_log_item attached to the buffer (which
    holds a reference to the buffer), but it is not freeing the
    xfs_buf_log_item. Hence nothing will ever release the buffer, and
    the unmount hangs waiting for this reference to go away.

    The fix is simple - xfs_buf_item_unlock needs to detect the last
    reference going away in this case and free the xfs_buf_log_item to
    release the reference it holds on the buffer.

    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Ben Myers <bpm at sgi.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

commit 4d559a3bcb7383f34334092af07e68fb60910684
Author: Dave Chinner <dchinner at redhat.com>
Date:   Mon Jan 21 23:53:54 2013 +1100

    xfs: limit speculative prealloc near ENOSPC thresholds

    There is a window on small filesytsems where specualtive
    preallocation can be larger than that ENOSPC throttling thresholds,
    resulting in specualtive preallocation trying to reserve more space
    than there is space available. This causes immediate ENOSPC to be
    triggered, prealloc to be turned off and flushing to occur. One the
    next write (i.e. next 4k page), we do exactly the same thing, and so
    effective drive into synchronous 4k writes by triggering ENOSPC
    flushing on every page while in the window between the prealloc size
    and the ENOSPC prealloc throttle threshold.

    Fix this by checking to see if the prealloc size would consume all
    free space, and throttle it appropriately to avoid premature
    ENOSPC...

    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Brian Foster <bfoster at redhat.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

commit 10616b806d1d7835b1d23b8d75ef638f92cb98b6
Author: Dave Chinner <dchinner at redhat.com>
Date:   Mon Jan 21 23:53:52 2013 +1100

    xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end

    When _xfs_buf_find is passed an out of range address, it will fail
    to find a relevant struct xfs_perag and oops with a null
    dereference. This can happen when trying to walk a filesystem with a
    metadata inode that has a partially corrupted extent map (i.e. the
    block number returned is corrupt, but is otherwise intact) and we
    try to read from the corrupted block address.

    In this case, just fail the lookup. If it is readahead being issued,
    it will simply not be done, but if it is real read that fails we
    will get an error being reported.  Ideally this case should result
    in an EFSCORRUPTED error being reported, but we cannot return an
    error through xfs_buf_read() or xfs_buf_get() so this lookup failure
    may result in ENOMEM or EIO errors being reported instead.

    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Brian Foster <bfoster at redhat.com>
    Reviewed-by: Ben Myers <bpm at sgi.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

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

Summary of changes:
 fs/xfs/xfs_aops.c     |  2 +-
 fs/xfs/xfs_buf.c      | 20 ++++++++++++++++++++
 fs/xfs/xfs_buf_item.c | 12 ++++++++++--
 fs/xfs/xfs_iomap.c    |  9 +++++++++
 fs/xfs/xfs_trace.h    |  1 +
 5 files changed, 41 insertions(+), 3 deletions(-)

hooks/post-receive
-- 
XFS development tree