xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, xfs-misc-fixes-3.17-2, create

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, xfs-misc-fixes-3.17-2, created. xfs-for-linus-3.16-rc1-13119-g4ef897a
From: xfs@xxxxxxxxxxx
Date: Sun, 3 Aug 2014 23:05:43 -0500 (CDT)
Delivered-to: xfs@xxxxxxxxxxx
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, xfs-misc-fixes-3.17-2 has been created
        at  4ef897a27543b513351262881660147366c042a1 (commit)

- Log -----------------------------------------------------------------
commit 4ef897a27543b513351262881660147366c042a1
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 13:44:08 2014 +1000

    xfs: flush both inodes in xfs_swap_extents
    
    We need to treat both inodes identically from a page cache point of
    view when prepareing them for extent swapping. We don't do this
    right now - we assume that one of the inodes empty, because that's
    what xfs_fsr currently does. Remove this assumption from the code.
    
    While factoring out the flushing and related checks, move the
    transactions reservation to immeidately after the flushes so that we
    don't need to pick up and then drop the ilock to do the transaction
    reservation. There are no issues with aborting the transaction it if
    the checks fail before we join the inodes to the transaction and
    dirty them, so this is a safe change to make.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit 812176832169c77b4bacddd01edc3e55340263fd
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 13:29:32 2014 +1000

    xfs: fix swapext ilock deadlock
    
    xfs_swap_extents() holds the ilock over a call to
    filemap_write_and_wait(), which can then try to write data and take
    the ilock. That causes a self-deadlock.
    
    Fix the deadlock and clean up the code by separating the locking
    appropriately. Add a lockflags variable to track what locks we are
    holding as we gain and drop them and cleanup the error handling to
    always use "out_unlock" with the lockflags variable.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit b92cc59f69537f26d5a42e4171ccc864ae4d9383
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 13:28:20 2014 +1000

    xfs: kill xfs_vnode.h
    
    Move the IO flag definitions to xfs_inode.h and kill the header file
    as it is now empty.
    
    Removing the xfs_vnode.h file showed up an implicit header include
    path:
        xfs_linux.h -> xfs_vnode.h -> xfs_fs.h
    
    And so every xfs header file has been inplicitly been including
    xfs_fs.h where it is needed or not. Hence the removal of xfs_vnode.h
    causes all sorts of build issues because BBTOB() and friends are no
    longer automatically included in the build. This also gets fixed.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit dd8c38bab0d88615e0bdf013e6de3d4345f8cda2
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 13:23:35 2014 +1000

    xfs: kill VN_MAPPED
    
    Only one user, no longer needed.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit 2667c6f935d979cea1ab7fa58568fd0fd725525f
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 13:23:15 2014 +1000

    xfs: kill VN_CACHED
    
    Only has 2 users, has outlived it's usefulness.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit eac152b4742ec5f1ed04d73d699ae2be3607d56b
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 13:22:49 2014 +1000

    xfs: kill VN_DIRTY()
    
    Only one user of the macro and the dirty mapping check is redundant
    so just get rid of it.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit ad3714b82c631a34724da09a7daa53afcab952fa
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 12:59:31 2014 +1000

    xfs: dquot recovery needs verifiers
    
    dquot recovery should add verifiers to the dquot buffers that it
    recovers changes into. Unfortunately, it doesn't attached the
    verifiers to the buffers in a consistent manner. For example,
    xlog_recover_dquot_pass2() reads dquot buffers without a verifier
    and then writes it without ever having attached a verifier to the
    buffer.
    
    Further, dquot buffer recovery may write a dquot buffer that has not
    been modified, or indeed, shoul dbe written because quotas are not
    enabled and hence changes to the buffer were not replayed. In this
    case, we again write buffers without verifiers attached because that
    doesn't happen until after the buffer changes have been replayed.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit 5fd364fee81a7888af806e42ed8a91c845894f2d
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 12:43:26 2014 +1000

    xfs: quotacheck leaves dquot buffers without verifiers
    
    When running xfs/305, I noticed that quotacheck was flushing dquot
    buffers that did not have the xfs_dquot_buf_ops verifiers attached:
    
    XFS (vdb): _xfs_buf_ioapply: no ops on block 0x1dc8/0x1dc8
    ffff880052489000: 44 51 01 04 00 00 65 b8 00 00 00 00 00 00 00 00  
DQ....e.........
    ffff880052489010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
................
    ffff880052489020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
................
    ffff880052489030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
................
    CPU: 1 PID: 2376 Comm: mount Not tainted 3.16.0-rc2-dgc+ #306
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
     ffff88006fe38000 ffff88004a0ffae8 ffffffff81cf1cca 0000000000000001
     ffff88004a0ffb88 ffffffff814d50ca 000010004a0ffc70 0000000000000000
     ffff88006be56dc4 0000000000000021 0000000000001dc8 ffff88007c773d80
    Call Trace:
     [<ffffffff81cf1cca>] dump_stack+0x45/0x56
     [<ffffffff814d50ca>] _xfs_buf_ioapply+0x3ca/0x3d0
     [<ffffffff810db520>] ? wake_up_state+0x20/0x20
     [<ffffffff814d51f5>] ? xfs_bdstrat_cb+0x55/0xb0
     [<ffffffff814d513b>] xfs_buf_iorequest+0x6b/0xd0
     [<ffffffff814d51f5>] xfs_bdstrat_cb+0x55/0xb0
     [<ffffffff814d53ab>] __xfs_buf_delwri_submit+0x15b/0x220
     [<ffffffff814d6040>] ? xfs_buf_delwri_submit+0x30/0x90
     [<ffffffff814d6040>] xfs_buf_delwri_submit+0x30/0x90
     [<ffffffff8150f89d>] xfs_qm_quotacheck+0x17d/0x3c0
     [<ffffffff81510591>] xfs_qm_mount_quotas+0x151/0x1e0
     [<ffffffff814ed01c>] xfs_mountfs+0x56c/0x7d0
     [<ffffffff814f0f12>] xfs_fs_fill_super+0x2c2/0x340
     [<ffffffff811c9fe4>] mount_bdev+0x194/0x1d0
     [<ffffffff814f0c50>] ? xfs_finish_flags+0x170/0x170
     [<ffffffff814ef0f5>] xfs_fs_mount+0x15/0x20
     [<ffffffff811ca8c9>] mount_fs+0x39/0x1b0
     [<ffffffff811e4d67>] vfs_kern_mount+0x67/0x120
     [<ffffffff811e757e>] do_mount+0x23e/0xad0
     [<ffffffff8117abde>] ? __get_free_pages+0xe/0x50
     [<ffffffff811e71e6>] ? copy_mount_options+0x36/0x150
     [<ffffffff811e8103>] SyS_mount+0x83/0xc0
     [<ffffffff81cfd40b>] tracesys+0xdd/0xe2
    
    This was caused by dquot buffer readahead not attaching a verifier
    structure to the buffer when readahead was issued, resulting in the
    followup read of the buffer finding a valid buffer and so not
    attaching new verifiers to the buffer as part of the read.
    
    Also, when a verifier failure occurs, we then read the buffer
    without verifiers. Attach the verifiers manually after this read so
    that if the buffer is then written it will be verified that the
    corruption has been repaired.
    
    Further, when flushing a dquot we don't ask for a verifier when
    reading in the dquot buffer the dquot belongs to. Most of the time
    this isn't an issue because the buffer is still cached, but when it
    is not cached it will result in writing the dquot buffer without
    having the verfier attached.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit 67dc288c21064b31a98a53dc64f6b9714b819fd6
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 12:43:06 2014 +1000

    xfs: ensure verifiers are attached to recovered buffers
    
    Crash testing of CRC enabled filesystems has resulted in a number of
    reports of bad CRCs being detected after the filesystem was mounted.
    Errors such as the following were being seen:
    
    XFS (sdb3): Mounting V5 Filesystem
    XFS (sdb3): Starting recovery (logdev: internal)
    XFS (sdb3): Metadata CRC error detected at xfs_agf_read_verify+0x5a/0x100 
[xfs], block 0x1
    XFS (sdb3): Unmount and run xfs_repair
    XFS (sdb3): First 64 bytes of corrupted metadata buffer:
    ffff880136ffd600: 58 41 47 46 00 00 00 01 00 00 00 00 00 0f aa 40  
XAGF...........@
    ffff880136ffd610: 00 02 6d 53 00 02 77 f8 00 00 00 00 00 00 00 01  
..mS..w.........
    ffff880136ffd620: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03  
................
    ffff880136ffd630: 00 00 00 04 00 08 81 d0 00 08 81 a7 00 00 00 00  
................
    XFS (sdb3): metadata I/O error: block 0x1 ("xfs_trans_read_buf_map") error 
74 numblks 1
    
    The errors were typically being seen in AGF, AGI and their related
    btree block buffers some time after log recovery had run. Often it
    wasn't until later subsequent mounts that the problem was
    discovered. The common symptom was a buffer with the correct
    contents, but a CRC and an LSN that matched an older version of the
    contents.
    
    Some debug added to _xfs_buf_ioapply() indicated that buffers were
    being written without verifiers attached to them from log recovery,
    and Jan Kara isolated the cause to log recovery readahead an dit's
    interactions with buffers that had a more recent LSN on disk than
    the transaction being recovered. In this case, the buffer did not
    get a verifier attached, and os when the second phase of log
    recovery ran and recovered EFIs and unlinked inodes, the buffers
    were modified and written without the verifier running. Hence they
    had up to date contents, but stale LSNs and CRCs.
    
    Fix it by attaching verifiers to buffers we skip due to future LSN
    values so they don't escape into the buffer cache without the
    correct verifier attached.
    
    This patch is based on analysis and a patch from Jan Kara.
    
    cc: <stable@xxxxxxxxxxxxxxx>
    Reported-by: Jan Kara <jack@xxxxxxx>
    Reported-by: Fanael Linithien <fanael4@xxxxxxxxx>
    Reported-by: Grozdan <neutrino8@xxxxxxxxx>
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit 400b9d88757c0bfbdfa97014e090ec40a31c1282
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Aug 4 12:42:40 2014 +1000

    xfs: catch buffers written without verifiers attached
    
    We recently had a bug where buffers were slipping through log
    recovery without any verifier attached to them. This was resulting
    in on-disk CRC mismatches for valid data. Add some warning code to
    catch this occurrence so that we catch such bugs during development
    rather than not being aware they exist.
    
    Note that we cannot do this verification unconditionally as non-CRC
    filesystems don't always attach verifiers to the buffers being
    written. e.g. during log recovery we cannot identify all the
    different types of buffers correctly on non-CRC filesystems, so we
    can't attach the correct verifiers in all cases and so we don't
    attach any. Hence we don't want on non-CRC filesystems to avoid
    spamming the logs with false indications.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

commit 5ef828c4152726f56751c78ea844f08d2b2a4fa3
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date:   Mon Aug 4 11:35:44 2014 +1000

    xfs: avoid false quotacheck after unclean shutdown
    
    The commit
    
    83e782e xfs: Remove incore use of XFS_OQUOTA_ENFD and XFS_OQUOTA_CHKD
    
    added a new function xfs_sb_quota_from_disk() which swaps
    on-disk XFS_OQUOTA_* flags for in-core XFS_GQUOTA_* and XFS_PQUOTA_*
    flags after the superblock is read.
    
    However, if log recovery is required, the superblock is read again,
    and the modified in-core flags are re-read from disk, so we have
    XFS_OQUOTA_* flags in memory again.  This causes the
    XFS_QM_NEED_QUOTACHECK() test to be true, because the XFS_OQUOTA_CHKD
    is still set, and not XFS_GQUOTA_CHKD or XFS_PQUOTA_CHKD.
    
    Change xfs_sb_from_disk to call xfs_sb_quota_from disk and always
    convert the disk flags to in-memory flags.
    
    Add a lower-level function which can be called with "false" to
    not convert the flags, so that the sb verifier can verify
    exactly what was on disk, per Brian Foster's suggestion.
    
    Reported-by: Cyril B. <cbay@xxxxxxxxxxxxx>
    Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>

commit eedf32bfcace7d8e20cc66757d74fc68f3439ff7
Author: Brian Foster <bfoster@xxxxxxxxxx>
Date:   Mon Aug 4 11:35:35 2014 +1000

    xfs: fix rounding error of fiemap length parameter
    
    The offset and length parameters are converted from bytes to basic
    blocks by xfs_vn_fiemap(). The BTOBB() converter rounds the value up to
    the nearest basic block. This leads to unexpected behavior when
    unaligned offsets are provided to FIEMAP.
    
    Fix the conversions of byte values to block values to cover the provided
    offsets. Round down the start offset to the nearest basic block.
    Calculate the end offset based on the provided values, round up and
    calculate length based on the start block offset.
    
    Reported-by: Chandan Rajendra <chandan@xxxxxxxxxxxxxxxxxx>
    Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
    Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

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


hooks/post-receive
-- 
XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, xfs-misc-fixes-3.17-2, created. xfs-for-linus-3.16-rc1-13119-g4ef897a, xfs <=