1. 10 6月, 2021 1 次提交
  2. 02 6月, 2021 2 次提交
    • D
      xfs: move xfs_perag_get/put to xfs_ag.[ch] · 9bbafc71
      Dave Chinner 提交于
      They are AG functions, not superblock functions, so move them to the
      appropriate location.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      9bbafc71
    • A
      xfs: Add delay ready attr remove routines · 2b74b03c
      Allison Henderson 提交于
      This patch modifies the attr remove routines to be delay ready. This
      means they no longer roll or commit transactions, but instead return
      -EAGAIN to have the calling routine roll and refresh the transaction. In
      this series, xfs_attr_remove_args is merged with
      xfs_attr_node_removename become a new function, xfs_attr_remove_iter.
      This new version uses a sort of state machine like switch to keep track
      of where it was when EAGAIN was returned. A new version of
      xfs_attr_remove_args consists of a simple loop to refresh the
      transaction until the operation is completed. A new XFS_DAC_DEFER_FINISH
      flag is used to finish the transaction where ever the existing code used
      to.
      
      Calls to xfs_attr_rmtval_remove are replaced with the delay ready
      version __xfs_attr_rmtval_remove. We will rename
      __xfs_attr_rmtval_remove back to xfs_attr_rmtval_remove when we are
      done.
      
      xfs_attr_rmtval_remove itself is still in use by the set routines (used
      during a rename).  For reasons of preserving existing function, we
      modify xfs_attr_rmtval_remove to call xfs_defer_finish when the flag is
      set.  Similar to how xfs_attr_remove_args does here.  Once we transition
      the set routines to be delay ready, xfs_attr_rmtval_remove is no longer
      used and will be removed.
      
      This patch also adds a new struct xfs_delattr_context, which we will use
      to keep track of the current state of an attribute operation. The new
      xfs_delattr_state enum is used to track various operations that are in
      progress so that we know not to repeat them, and resume where we left
      off before EAGAIN was returned to cycle out the transaction. Other
      members take the place of local variables that need to retain their
      values across multiple function calls.  See xfs_attr.h for a more
      detailed diagram of the states.
      Signed-off-by: NAllison Henderson <allison.henderson@oracle.com>
      Reviewed-by: NChandan Babu R <chandanrlinux@gmail.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      2b74b03c
  3. 16 4月, 2021 2 次提交
  4. 08 4月, 2021 1 次提交
  5. 19 11月, 2020 1 次提交
    • G
      xfs: fix forkoff miscalculation related to XFS_LITINO(mp) · ada49d64
      Gao Xiang 提交于
      Currently, commit e9e2eae8 dropped a (int) decoration from
      XFS_LITINO(mp), and since sizeof() expression is also involved,
      the result of XFS_LITINO(mp) is simply as the size_t type
      (commonly unsigned long).
      
      Considering the expression in xfs_attr_shortform_bytesfit():
        offset = (XFS_LITINO(mp) - bytes) >> 3;
      let "bytes" be (int)340, and
          "XFS_LITINO(mp)" be (unsigned long)336.
      
      on 64-bit platform, the expression is
        offset = ((unsigned long)336 - (int)340) >> 3 =
                 (int)(0xfffffffffffffffcUL >> 3) = -1
      
      but on 32-bit platform, the expression is
        offset = ((unsigned long)336 - (int)340) >> 3 =
                 (int)(0xfffffffcUL >> 3) = 0x1fffffff
      instead.
      
      so offset becomes a large positive number on 32-bit platform, and
      cause xfs_attr_shortform_bytesfit() returns maxforkoff rather than 0.
      
      Therefore, one result is
        "ASSERT(new_size <= XFS_IFORK_SIZE(ip, whichfork));"
      
      assertion failure in xfs_idata_realloc(), which was also the root
      cause of the original bugreport from Dennis, see:
         https://bugzilla.redhat.com/show_bug.cgi?id=1894177
      
      And it can also be manually triggered with the following commands:
        $ touch a;
        $ setfattr -n user.0 -v "`seq 0 80`" a;
        $ setfattr -n user.1 -v "`seq 0 80`" a
      
      on 32-bit platform.
      
      Fix the case in xfs_attr_shortform_bytesfit() by bailing out
      "XFS_LITINO(mp) < bytes" in advance suggested by Eric and a misleading
      comment together with this bugfix suggested by Darrick. It seems the
      other users of XFS_LITINO(mp) are not impacted.
      
      Fixes: e9e2eae8 ("xfs: only check the superblock version for dinode size calculation")
      Cc: <stable@vger.kernel.org> # 5.7+
      Reported-and-tested-by: NDennis Gilmore <dgilmore@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      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>
      ada49d64
  6. 16 9月, 2020 4 次提交
  7. 27 8月, 2020 2 次提交
  8. 29 7月, 2020 4 次提交
  9. 27 5月, 2020 1 次提交
    • D
      xfs: more lockdep whackamole with kmem_alloc* · 6dcde60e
      Darrick J. Wong 提交于
      Dave Airlie reported the following lockdep complaint:
      
      >  ======================================================
      >  WARNING: possible circular locking dependency detected
      >  5.7.0-0.rc5.20200515git1ae7efb3.1.fc33.x86_64 #1 Not tainted
      >  ------------------------------------------------------
      >  kswapd0/159 is trying to acquire lock:
      >  ffff9b38d01a4470 (&xfs_nondir_ilock_class){++++}-{3:3},
      >  at: xfs_ilock+0xde/0x2c0 [xfs]
      >
      >  but task is already holding lock:
      >  ffffffffbbb8bd00 (fs_reclaim){+.+.}-{0:0}, at:
      >  __fs_reclaim_acquire+0x5/0x30
      >
      >  which lock already depends on the new lock.
      >
      >
      >  the existing dependency chain (in reverse order) is:
      >
      >  -> #1 (fs_reclaim){+.+.}-{0:0}:
      >         fs_reclaim_acquire+0x34/0x40
      >         __kmalloc+0x4f/0x270
      >         kmem_alloc+0x93/0x1d0 [xfs]
      >         kmem_alloc_large+0x4c/0x130 [xfs]
      >         xfs_attr_copy_value+0x74/0xa0 [xfs]
      >         xfs_attr_get+0x9d/0xc0 [xfs]
      >         xfs_get_acl+0xb6/0x200 [xfs]
      >         get_acl+0x81/0x160
      >         posix_acl_xattr_get+0x3f/0xd0
      >         vfs_getxattr+0x148/0x170
      >         getxattr+0xa7/0x240
      >         path_getxattr+0x52/0x80
      >         do_syscall_64+0x5c/0xa0
      >         entry_SYSCALL_64_after_hwframe+0x49/0xb3
      >
      >  -> #0 (&xfs_nondir_ilock_class){++++}-{3:3}:
      >         __lock_acquire+0x1257/0x20d0
      >         lock_acquire+0xb0/0x310
      >         down_write_nested+0x49/0x120
      >         xfs_ilock+0xde/0x2c0 [xfs]
      >         xfs_reclaim_inode+0x3f/0x400 [xfs]
      >         xfs_reclaim_inodes_ag+0x20b/0x410 [xfs]
      >         xfs_reclaim_inodes_nr+0x31/0x40 [xfs]
      >         super_cache_scan+0x190/0x1e0
      >         do_shrink_slab+0x184/0x420
      >         shrink_slab+0x182/0x290
      >         shrink_node+0x174/0x680
      >         balance_pgdat+0x2d0/0x5f0
      >         kswapd+0x21f/0x510
      >         kthread+0x131/0x150
      >         ret_from_fork+0x3a/0x50
      >
      >  other info that might help us debug this:
      >
      >   Possible unsafe locking scenario:
      >
      >         CPU0                    CPU1
      >         ----                    ----
      >    lock(fs_reclaim);
      >                                 lock(&xfs_nondir_ilock_class);
      >                                 lock(fs_reclaim);
      >    lock(&xfs_nondir_ilock_class);
      >
      >   *** DEADLOCK ***
      >
      >  4 locks held by kswapd0/159:
      >   #0: ffffffffbbb8bd00 (fs_reclaim){+.+.}-{0:0}, at:
      >  __fs_reclaim_acquire+0x5/0x30
      >   #1: ffffffffbbb7cef8 (shrinker_rwsem){++++}-{3:3}, at:
      >  shrink_slab+0x115/0x290
      >   #2: ffff9b39f07a50e8
      >  (&type->s_umount_key#56){++++}-{3:3}, at: super_cache_scan+0x38/0x1e0
      >   #3: ffff9b39f077f258
      >  (&pag->pag_ici_reclaim_lock){+.+.}-{3:3}, at:
      >  xfs_reclaim_inodes_ag+0x82/0x410 [xfs]
      
      This is a known false positive because inodes cannot simultaneously be
      getting reclaimed and the target of a getxattr operation, but lockdep
      doesn't know that.  We can (selectively) shut up lockdep until either
      it gets smarter or we change inode reclaim not to require the ILOCK by
      applying a stupid GFP_NOLOCKDEP bandaid.
      Reported-by: NDave Airlie <airlied@gmail.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Tested-by: NDave Airlie <airlied@gmail.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      6dcde60e
  10. 20 5月, 2020 4 次提交
  11. 19 3月, 2020 1 次提交
  12. 12 3月, 2020 1 次提交
  13. 03 3月, 2020 5 次提交
  14. 10 1月, 2020 1 次提交
  15. 23 11月, 2019 3 次提交
  16. 16 11月, 2019 1 次提交
    • B
      xfs: fix attr leaf header freemap.size underflow · 2a2b5932
      Brian Foster 提交于
      The leaf format xattr addition helper xfs_attr3_leaf_add_work()
      adjusts the block freemap in a couple places. The first update drops
      the size of the freemap that the caller had already selected to
      place the xattr name/value data. Before the function returns, it
      also checks whether the entries array has encroached on a freemap
      range by virtue of the new entry addition. This is necessary because
      the entries array grows from the start of the block (but end of the
      block header) towards the end of the block while the name/value data
      grows from the end of the block in the opposite direction. If the
      associated freemap is already empty, however, size is zero and the
      subtraction underflows the field and causes corruption.
      
      This is reproduced rarely by generic/070. The observed behavior is
      that a smaller sized freemap is aligned to the end of the entries
      list, several subsequent xattr additions land in larger freemaps and
      the entries list expands into the smaller freemap until it is fully
      consumed and then underflows. Note that it is not otherwise a
      corruption for the entries array to consume an empty freemap because
      the nameval list (i.e. the firstused pointer in the xattr header)
      starts beyond the end of the corrupted freemap.
      
      Update the freemap size modification to account for the fact that
      the freemap entry can be empty and thus stale.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      2a2b5932
  17. 11 11月, 2019 4 次提交
  18. 05 11月, 2019 1 次提交
  19. 30 10月, 2019 1 次提交