[XFS updates] XFS development tree branch, master, updated. v3.7-rc1-77-gb870553

Thu Nov 29 15:16:28 CST 2012

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, master has been updated
  b870553 xfs: fix stray dquot unlock when reclaiming dquots
  437a255 xfs: fix direct IO nested transaction deadlock.
  ef9d873 xfs: byte range granularity for XFS_IOC_ZERO_RANGE
      from  7c4cebe8e02dd0b0e655605442bbe9268db9ed4f (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 b870553cdecb26d5291af09602352b763e323df2
Author: Dave Chinner <dchinner at redhat.com>
Date:   Wed Nov 28 13:01:02 2012 +1100

    xfs: fix stray dquot unlock when reclaiming dquots

    When we fail to get a dquot lock during reclaim, we jump to an error
    handler that unlocks the dquot. This is wrong as we didn't lock the
    dquot, and unlocking it means who-ever is holding the lock has had
    it silently taken away, and hence it results in a lock imbalance.

    Found by inspection while modifying the code for the numa-lru
    patchset. This fixes a random hang I've been seeing on xfstest 232
    for the past several months.

    cc: <stable at vger.kernel.org>
    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 437a255aa23766666aec78af63be4c253faa8d57
Author: Dave Chinner <dchinner at redhat.com>
Date:   Wed Nov 28 13:01:00 2012 +1100

    xfs: fix direct IO nested transaction deadlock.

    The direct IO path can do a nested transaction reservation when
    writing past the EOF. The first transaction is the append
    transaction for setting the filesize at IO completion, but we can
    also need a transaction for allocation of blocks. If the log is low
    on space due to reservations and small log, the append transaction
    can be granted after wating for space as the only active transaction
    in the system. This then attempts a reservation for an allocation,
    which there isn't space in the log for, and the reservation sleeps.
    The result is that there is nothing left in the system to wake up
    all the processes waiting for log space to come free.

    The stack trace that shows this deadlock is relatively innocuous:

     xlog_grant_head_wait
     xlog_grant_head_check
     xfs_log_reserve
     xfs_trans_reserve
     xfs_iomap_write_direct
     __xfs_get_blocks
     xfs_get_blocks_direct
     do_blockdev_direct_IO
     __blockdev_direct_IO
     xfs_vm_direct_IO
     generic_file_direct_write
     xfs_file_dio_aio_writ
     xfs_file_aio_write
     do_sync_write
     vfs_write

    This was discovered on a filesystem with a log of only 10MB, and a
    log stripe unit of 256k whih increased the base reservations by
    512k. Hence a allocation transaction requires 1.2MB of log space to
    be available instead of only 260k, and so greatly increased the
    chance that there wouldn't be enough log space available for the
    nested transaction to succeed. The key to reproducing it is this
    mkfs command:

    mkfs.xfs -f -d agcount=16,su=256k,sw=12 -l su=256k,size=2560b $SCRATCH_DEV

    The test case was a 1000 fsstress processes running with random
    freeze and unfreezes every few seconds. Thanks to Eryu Guan
    (eguan at redhat.com) for writing the test that found this on a system
    with a somewhat unique default configuration....

    cc: <stable at vger.kernel.org>
    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Christoph Hellwig <hch at lst.de>
    Reviewed-by: Andrew Dahl <adahl at sgi.com>
    Signed-off-by: Ben Myers <bpm at sgi.com>

commit ef9d873344ff9f5084eacb9f3735982314dfda9e
Author: Dave Chinner <dchinner at redhat.com>
Date:   Thu Nov 29 15:26:33 2012 +1100

    xfs: byte range granularity for XFS_IOC_ZERO_RANGE

    XFS_IOC_ZERO_RANGE simply does not work properly for non page cache
    aligned ranges. Neither test 242 or 290 exercise this correctly, so
    the behaviour is completely busted even though the tests pass.

    Fix it to support full byte range granularity as was originally
    intended for this ioctl.

    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_aops.c     |   81 +++++++++++++++--------------------------
 fs/xfs/xfs_file.c     |    2 +-
 fs/xfs/xfs_log.c      |    3 +-
 fs/xfs/xfs_qm.c       |   15 ++++----
 fs/xfs/xfs_vnodeops.c |   96 ++++++++++++++++++++++++++++++++++++++-----------
 fs/xfs/xfs_vnodeops.h |    1 +
 6 files changed, 115 insertions(+), 83 deletions(-)

hooks/post-receive
-- 
XFS development tree