1. 04 4月, 2023 1 次提交
  2. 27 12月, 2021 2 次提交
    • G
      xfs: Fix fall-through warnings for Clang · 1ef907ec
      Gustavo A. R. Silva 提交于
      mainline-inclusion
      from mainline-v5.13-rc2
      commit 53004ee7
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO
      CVE: NA
      
      Reference:
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=53004ee78d6273c994534ccf79d993098ac89769
      
      -------------------------------------------------
      
      In preparation to enable -Wimplicit-fallthrough for Clang, fix
      the following warnings by replacing /* fall through */ comments,
      and its variants, with the new pseudo-keyword macro fallthrough:
      
      fs/xfs/libxfs/xfs_alloc.c:3167:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/libxfs/xfs_da_btree.c:286:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/libxfs/xfs_ag_resv.c:346:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/libxfs/xfs_ag_resv.c:388:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_bmap_util.c:246:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_export.c:88:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_export.c:96:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_file.c:867:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_ioctl.c:562:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_ioctl.c:1548:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_iomap.c:1040:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_inode.c:852:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_log.c:2627:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/xfs_trans_buf.c:298:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/scrub/bmap.c:275:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/scrub/btree.c:48:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/scrub/common.c:85:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/scrub/common.c:138:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/scrub/common.c:698:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/scrub/dabtree.c:51:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/scrub/repair.c:951:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      fs/xfs/scrub/agheader.c:89:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
      
      Notice that Clang doesn't recognize /* fall through */ comments as
      implicit fall-through markings, so in order to globally enable
      -Wimplicit-fallthrough for Clang, these comments need to be
      replaced with fallthrough; in the whole codebase.
      
      Link: https://github.com/KSPP/linux/issues/115Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
      Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
      Reviewed-by: NLihong Kou <koulihong@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      1ef907ec
    • D
      xfs: remove obsolete AGF counter debugging · dc0c7ae0
      Darrick J. Wong 提交于
      mainline-inclusion
      from mainline-v5.12-rc4
      commit 1aec7c3d
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1aec7c3d05670b92b7339b19999009a93808efb9
      
      -------------------------------------------------
      
      In commit f8f2835a we changed the behavior of XFS to use EFIs to
      remove blocks from an overfilled AGFL because there were complaints
      about transaction overruns that stemmed from trying to free multiple
      blocks in a single transaction.
      
      Unfortunately, that commit missed a subtlety in the debug-mode
      transaction accounting when a realtime volume is attached.  If a
      realtime file undergoes a data fork mapping change such that realtime
      extents are allocated (or freed) in the same transaction that a data
      device block is also allocated (or freed), we can trip a debugging
      assertion.  This can happen (for example) if a realtime extent is
      allocated and it is necessary to reshape the bmbt to hold the new
      mapping.
      
      When we go to allocate a bmbt block from an AG, the first thing the data
      device block allocator does is ensure that the freelist is the proper
      length.  If the freelist is too long, it will trim the freelist to the
      proper length.
      
      In debug mode, trimming the freelist calls xfs_trans_agflist_delta() to
      record the decrement in the AG free list count.  Prior to f8f28 we would
      put the free block back in the free space btrees in the same
      transaction, which calls xfs_trans_agblocks_delta() to record the
      increment in the AG free block count.  Since AGFL blocks are included in
      the global free block count (fdblocks), there is no corresponding
      fdblocks update, so the AGFL free satisfies the following condition in
      xfs_trans_apply_sb_deltas:
      
      	/*
      	 * Check that superblock mods match the mods made to AGF counters.
      	 */
      	ASSERT((tp->t_fdblocks_delta + tp->t_res_fdblocks_delta) ==
      	       (tp->t_ag_freeblks_delta + tp->t_ag_flist_delta +
      		tp->t_ag_btree_delta));
      
      The comparison here used to be: (X + 0) == ((X+1) + -1 + 0), where X is
      the number blocks that were allocated.
      
      After commit f8f28 we defer the block freeing to the next chained
      transaction, which means that the calls to xfs_trans_agflist_delta and
      xfs_trans_agblocks_delta occur in separate transactions.  The (first)
      transaction that shortens the free list trips on the comparison, which
      has now become:
      
      (X + 0) == ((X) + -1 + 0)
      
      because we haven't freed the AGFL block yet; we've only logged an
      intention to free it.  When the second transaction (the deferred free)
      commits, it will evaluate the expression as:
      
      (0 + 0) == (1 + 0 + 0)
      
      and trip over that in turn.
      
      At this point, the astute reader may note that the two commits tagged by
      this patch have been in the kernel for a long time but haven't generated
      any bug reports.  How is it that the author became aware of this bug?
      
      This originally surfaced as an intermittent failure when I was testing
      realtime rmap, but a different bug report by Zorro Lang reveals the same
      assertion occuring on !lazysbcount filesystems.
      
      The common factor to both reports (and why this problem wasn't
      previously reported) becomes apparent if we consider when
      xfs_trans_apply_sb_deltas is called by __xfs_trans_commit():
      
      	if (tp->t_flags & XFS_TRANS_SB_DIRTY)
      		xfs_trans_apply_sb_deltas(tp);
      
      With a modern lazysbcount filesystem, transactions update only the
      percpu counters, so they don't need to set XFS_TRANS_SB_DIRTY, hence
      xfs_trans_apply_sb_deltas is rarely called.
      
      However, updates to the count of free realtime extents are not part of
      lazysbcount, so XFS_TRANS_SB_DIRTY will be set on transactions adding or
      removing data fork mappings to realtime files; similarly,
      XFS_TRANS_SB_DIRTY is always set on !lazysbcount filesystems.
      
      Dave mentioned in response to an earlier version of this patch:
      
      "IIUC, what you are saying is that this debug code is simply not
      exercised in normal testing and hasn't been for the past decade?  And it
      still won't be exercised on anything other than realtime device testing?
      
      "...it was debugging code from 1994 that was largely turned into dead
      code when lazysbcounters were introduced in 2007. Hence I'm not sure it
      holds any value anymore."
      
      This debugging code isn't especially helpful - you can modify the
      flcount on one AG and the freeblks of another AG, and it won't trigger.
      Add the fact that nobody noticed for a decade, and let's just get rid of
      it (and start testing realtime :P).
      
      This bug was found by running generic/051 on either a V4 filesystem
      lacking lazysbcount; or a V5 filesystem with a realtime volume.
      
      Cc: bfoster@redhat.com, zlang@redhat.com
      Fixes: f8f2835a ("xfs: defer agfl block frees when dfops is available")
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
      Reviewed-by: NLihong Kou <koulihong@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      dc0c7ae0
  3. 29 10月, 2020 1 次提交
  4. 29 7月, 2020 1 次提交
  5. 14 7月, 2020 1 次提交
    • G
      xfs: get rid of unnecessary xfs_perag_{get,put} pairs · 92a00544
      Gao Xiang 提交于
      In the course of some operations, we look up the perag from
      the mount multiple times to get or change perag information.
      These are often very short pieces of code, so while the
      lookup cost is generally low, the cost of the lookup is far
      higher than the cost of the operation we are doing on the
      perag.
      
      Since we changed buffers to hold references to the perag
      they are cached in, many modification contexts already hold
      active references to the perag that are held across these
      operations. This is especially true for any operation that
      is serialised by an allocation group header buffer.
      
      In these cases, we can just use the buffer's reference to
      the perag to avoid needing to do lookups to access the
      perag. This means that many operations don't need to do
      perag lookups at all to access the perag because they've
      already looked up objects that own persistent references
      and hence can use that reference instead.
      
      Cc: Dave Chinner <dchinner@redhat.com>
      Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
      Signed-off-by: NGao Xiang <hsiangkao@redhat.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      92a00544
  6. 17 3月, 2020 1 次提交
  7. 14 3月, 2020 2 次提交
  8. 12 3月, 2020 3 次提交
  9. 03 3月, 2020 1 次提交
    • Z
      xfs: add agf freeblocks verify in xfs_agf_verify · d0c7feaf
      Zheng Bin 提交于
      We recently used fuzz(hydra) to test XFS and automatically generate
      tmp.img(XFS v5 format, but some metadata is wrong)
      
      xfs_repair information(just one AG):
      agf_freeblks 0, counted 3224 in ag 0
      agf_longest 536874136, counted 3224 in ag 0
      sb_fdblocks 613, counted 3228
      
      Test as follows:
      mount tmp.img tmpdir
      cp file1M tmpdir
      sync
      
      In 4.19-stable, sync will stuck, the reason is:
      xfs_mountfs
        xfs_check_summary_counts
          if ((!xfs_sb_version_haslazysbcount(&mp->m_sb) ||
             XFS_LAST_UNMOUNT_WAS_CLEAN(mp)) &&
             !xfs_fs_has_sickness(mp, XFS_SICK_FS_COUNTERS))
      	return 0;  -->just return, incore sb_fdblocks still be 613
          xfs_initialize_perag_data
      
      cp file1M tmpdir -->ok(write file to pagecache)
      sync -->stuck(write pagecache to disk)
      xfs_map_blocks
        xfs_iomap_write_allocate
          while (count_fsb != 0) {
            nimaps = 0;
            while (nimaps == 0) { --> endless loop
               nimaps = 1;
               xfs_bmapi_write(..., &nimaps) --> nimaps becomes 0 again
      xfs_bmapi_write
        xfs_bmap_alloc
          xfs_bmap_btalloc
            xfs_alloc_vextent
              xfs_alloc_fix_freelist
                xfs_alloc_space_available -->fail(agf_freeblks is 0)
      
      In linux-next, sync not stuck, cause commit c2b31643 ("xfs:
      use the latest extent at writeback delalloc conversion time") remove
      the above while, dmesg is as follows:
      [   55.250114] XFS (loop0): page discard on page ffffea0008bc7380, inode 0x1b0c, offset 0.
      
      Users do not know why this page is discard, the better soultion is:
      1. Like xfs_repair, make sure sb_fdblocks is equal to counted
      (xfs_initialize_perag_data did this, who is not called at this mount)
      2. Add agf verify, if fail, will tell users to repair
      
      This patch use the second soultion.
      Signed-off-by: NZheng Bin <zhengbin13@huawei.com>
      Signed-off-by: NRen Xudong <renxudong1@huawei.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      d0c7feaf
  10. 27 1月, 2020 3 次提交
  11. 19 12月, 2019 1 次提交
  12. 14 11月, 2019 1 次提交
  13. 13 11月, 2019 1 次提交
    • D
      xfs: kill the XFS_WANT_CORRUPT_* macros · f9e03706
      Darrick J. Wong 提交于
      The XFS_WANT_CORRUPT_* macros conceal subtle side effects such as the
      creation of local variables and redirections of the code flow.  This is
      pretty ugly, so replace them with explicit XFS_IS_CORRUPT tests that
      remove both of those ugly points.  The change was performed with the
      following coccinelle script:
      
      @@
      expression mp, test;
      identifier label;
      @@
      
      - XFS_WANT_CORRUPTED_GOTO(mp, test, label);
      + if (XFS_IS_CORRUPT(mp, !test)) { error = -EFSCORRUPTED; goto label; }
      
      @@
      expression mp, test;
      @@
      
      - XFS_WANT_CORRUPTED_RETURN(mp, test);
      + if (XFS_IS_CORRUPT(mp, !test)) return -EFSCORRUPTED;
      
      @@
      expression mp, lval, rval;
      @@
      
      - XFS_IS_CORRUPT(mp, !(lval == rval))
      + XFS_IS_CORRUPT(mp, lval != rval)
      
      @@
      expression mp, e1, e2;
      @@
      
      - XFS_IS_CORRUPT(mp, !(e1 && e2))
      + XFS_IS_CORRUPT(mp, !e1 || !e2)
      
      @@
      expression e1, e2;
      @@
      
      - !(e1 == e2)
      + e1 != e2
      
      @@
      expression e1, e2, e3, e4, e5, e6;
      @@
      
      - !(e1 == e2 && e3 == e4) || e5 != e6
      + e1 != e2 || e3 != e4 || e5 != e6
      
      @@
      expression e1, e2, e3, e4, e5, e6;
      @@
      
      - !(e1 == e2 || (e3 <= e4 && e5 <= e6))
      + e1 != e2 && (e3 > e4 || e5 > e6)
      
      @@
      expression mp, e1, e2;
      @@
      
      - XFS_IS_CORRUPT(mp, !(e1 <= e2))
      + XFS_IS_CORRUPT(mp, e1 > e2)
      
      @@
      expression mp, e1, e2;
      @@
      
      - XFS_IS_CORRUPT(mp, !(e1 < e2))
      + XFS_IS_CORRUPT(mp, e1 >= e2)
      
      @@
      expression mp, e1;
      @@
      
      - XFS_IS_CORRUPT(mp, !!e1)
      + XFS_IS_CORRUPT(mp, e1)
      
      @@
      expression mp, e1, e2;
      @@
      
      - XFS_IS_CORRUPT(mp, !(e1 || e2))
      + XFS_IS_CORRUPT(mp, !e1 && !e2)
      
      @@
      expression mp, e1, e2, e3, e4;
      @@
      
      - XFS_IS_CORRUPT(mp, !(e1 == e2) && !(e3 == e4))
      + XFS_IS_CORRUPT(mp, e1 != e2 && e3 != e4)
      
      @@
      expression mp, e1, e2, e3, e4;
      @@
      
      - XFS_IS_CORRUPT(mp, !(e1 <= e2) || !(e3 >= e4))
      + XFS_IS_CORRUPT(mp, e1 > e2 || e3 < e4)
      
      @@
      expression mp, e1, e2, e3, e4;
      @@
      
      - XFS_IS_CORRUPT(mp, !(e1 == e2) && !(e3 <= e4))
      + XFS_IS_CORRUPT(mp, e1 != e2 && e3 > e4)
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      f9e03706
  14. 11 11月, 2019 2 次提交
  15. 05 11月, 2019 1 次提交
  16. 04 11月, 2019 2 次提交
  17. 24 10月, 2019 1 次提交
  18. 22 10月, 2019 11 次提交
  19. 27 8月, 2019 1 次提交
  20. 03 7月, 2019 1 次提交
  21. 29 6月, 2019 2 次提交