1. 25 Feb, 2021 1 commit
    • Brian Foster's avatar
      xfs: don't reuse busy extents on extent trim · 06058bc4
      Brian Foster authored
      Freed extents are marked busy from the point the freeing transaction
      commits until the associated CIL context is checkpointed to the log.
      This prevents reuse and overwrite of recently freed blocks before
      the changes are committed to disk, which can lead to corruption
      after a crash. The exception to this rule is that metadata
      allocation is allowed to reuse busy extents because metadata changes
      are also logged.
      
      As of commit 97d3ac75 ("xfs: exact busy extent tracking"), XFS
      has allowed modification or complete invalidation of outstanding
      busy extents for metadata allocations. This implementation assumes
      that use of the associated extent is imminent, which is not always
      the case. For example, the trimmed extent might not satisfy the
      minimum length of the allocation request, or the allocation
      algorithm might be involved in a search for the optimal result based
      on locality.
      
      generic/019 reproduces a corruption caused by this scenario. First,
      a metadata block (usually a bmbt or symlink block) is freed from an
      inode. A subsequent bmbt split on an unrelated inode attempts a near
      mode allocation request that invalidates the busy block during the
      search, but does not ultimately allocate it. Due to the busy state
      invalidation, the block is no longer considered busy to subsequent
      allocation. A direct I/O write request immediately allocates the
      block and writes to it. Finally, the filesystem crashes while in a
      state where the initial metadata block free had not committed to the
      on-disk log. After recovery, the original metadata block is in its
      original location as expected, but has been corrupted by the
      aforementioned dio.
      
      This demonstrates that it is fundamentally unsafe to modify busy
      extent state for extents that are not guaranteed to be allocated.
      This applies to pretty much all of the code paths that currently
      trim busy extents for one reason or another. Therefore to address
      this problem, drop the reuse mechanism from the busy extent trim
      path. This code already knows how to return partial non-busy ranges
      of the targeted free extent and higher level code tracks the busy
      state of the allocation attempt. If a block allocation fails where
      one or more candidate extents is busy, we force the log and retry
      the allocation.
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChandan Babu R <chandanrlinux@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      06058bc4
  2. 24 Feb, 2021 1 commit
  3. 11 Feb, 2021 3 commits
  4. 09 Feb, 2021 1 commit
  5. 04 Feb, 2021 1 commit
    • Darrick J. Wong's avatar
      xfs: fix incorrect root dquot corruption error when switching group/project quota types · 45068063
      Darrick J. Wong authored
      While writing up a regression test for broken behavior when a chprojid
      request fails, I noticed that we were logging corruption notices about
      the root dquot of the group/project quota file at mount time when
      testing V4 filesystems.
      
      In commit afeda600, I was trying to improve ondisk dquot validation
      by making sure that when we load an ondisk dquot into memory on behalf
      of an incore dquot, the dquot id and type matches.  Unfortunately, I
      forgot that V4 filesystems only have two quota files, and can switch
      that file between group and project quota types at mount time.  When we
      perform that switch, we'll try to load the default quota limits from the
      root dquot prior to running quotacheck and log a corruption error when
      the types don't match.
      
      This is inconsequential because quotacheck will reset the second quota
      file as part of doing the switch, but we shouldn't leave scary messages
      in the kernel log.
      
      Fixes: afeda600 ("xfs: validate ondisk/incore dquot flags")
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChandan Babu R <chandanrlinux@gmail.com>
      45068063
  6. 03 Feb, 2021 33 commits