1. 18 1月, 2022 1 次提交
    • D
      xfs: kill the XFS_IOC_{ALLOC,FREE}SP* ioctls · 4d1b97f9
      Darrick J. Wong 提交于
      According to the glibc compat header for Irix 4, these ioctls originated
      in April 1991 as a (somewhat clunky) way to preallocate space at the end
      of a file on an EFS filesystem.  XFS, which was released in Irix 5.3 in
      December 1993, picked up these ioctls to maintain compatibility and they
      were ported to Linux in the early 2000s.
      
      Recently it was pointed out to me they still lurk in the kernel, even
      though the Linux fallocate syscall supplanted the functionality a long
      time ago.  fstests doesn't seem to include any real functional or stress
      tests for these ioctls, which means that the code quality is ... very
      questionable.  Most notably, it was a stale disk block exposure vector
      for 21 years and nobody noticed or complained.  As mature programmers
      say, "If you're not testing it, it's broken."
      
      Given all that, let's withdraw these ioctls from the XFS userspace API.
      Normally we'd set a long deprecation process, but I estimate that there
      aren't any real users, so let's trigger a warning in dmesg and return
      -ENOTTY.
      
      See: CVE-2021-4155
      
      Augments: 983d8e60 ("xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate")
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NEric Sandeen <sandeen@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      4d1b97f9
  2. 20 8月, 2021 3 次提交
  3. 13 7月, 2021 1 次提交
  4. 02 6月, 2021 1 次提交
  5. 27 5月, 2021 1 次提交
    • G
      xfs: Fix fall-through warnings for Clang · 53004ee7
      Gustavo A. R. Silva 提交于
      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>
      53004ee7
  6. 20 5月, 2021 1 次提交
  7. 17 5月, 2021 1 次提交
    • D
      xfs: adjust rt allocation minlen when extszhint > rtextsize · 9d5e8492
      Darrick J. Wong 提交于
      xfs_bmap_rtalloc doesn't handle realtime extent files with extent size
      hints larger than the rt volume's extent size properly, because
      xfs_bmap_extsize_align can adjust the offset/length parameters to try to
      fit the extent size hint.
      
      Under these conditions, minlen has to be large enough so that any
      allocation returned by xfs_rtallocate_extent will be large enough to
      cover at least one of the blocks that the caller asked for.  If the
      allocation is too short, bmapi_write will return no mapping for the
      requested range, which causes ENOSPC errors in other parts of the
      filesystem.
      
      Therefore, adjust minlen upwards to fix this.  This can be found by
      running generic/263 (g/127 or g/522) with a realtime extent size hint
      that's larger than the rt volume extent size.
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NAllison Henderson <allison.henderson@oracle.com>
      9d5e8492
  8. 16 4月, 2021 2 次提交
  9. 08 4月, 2021 6 次提交
  10. 04 2月, 2021 5 次提交
  11. 23 1月, 2021 3 次提交
  12. 22 10月, 2020 1 次提交
    • D
      xfs: fix fallocate functions when rtextsize is larger than 1 · 25219dbf
      Darrick J. Wong 提交于
      In commit fe341eb1, I forgot that xfs_free_file_space isn't strictly
      a "remove mapped blocks" function.  It is actually a function to zero
      file space by punching out the middle and writing zeroes to the
      unaligned ends of the specified range.  Therefore, putting a rtextsize
      alignment check in that function is wrong because that breaks unaligned
      ZERO_RANGE on the realtime volume.
      
      Furthermore, xfs_file_fallocate already has alignment checks for the
      functions require the file range to be aligned to the size of a
      fundamental allocation unit (which is 1 FSB on the data volume and 1 rt
      extent on the realtime volume).  Create a new helper to check fallocate
      arguments against the realtiem allocation unit size, fix the fallocate
      frontend to use it, fix free_file_space to delete the correct range, and
      remove a now redundant check from insert_file_space.
      
      NOTE: The realtime extent size is not required to be a power of two!
      
      Fixes: fe341eb1 ("xfs: ensure that fpunch, fcollapse, and finsert operations are aligned to rt extent size")
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NChandan Babu R <chandanrlinux@gmail.com>
      25219dbf
  13. 16 9月, 2020 1 次提交
  14. 27 8月, 2020 1 次提交
    • B
      xfs: finish dfops on every insert range shift iteration · 9c516e0e
      Brian Foster 提交于
      The recent change to make insert range an atomic operation used the
      incorrect transaction rolling mechanism. The explicit transaction
      roll does not finish deferred operations. This means that intents
      for rmapbt updates caused by extent shifts are not logged until the
      final transaction commits. Thus if a crash occurs during an insert
      range, log recovery might leave the rmapbt in an inconsistent state.
      This was discovered by repeated runs of generic/455.
      
      Update insert range to finish dfops on every shift iteration. This
      is similar to collapse range and ensures that intents are logged
      with the transactions that make associated changes.
      
      Fixes: dd87f87d ("xfs: rework insert range into an atomic operation")
      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>
      9c516e0e
  15. 17 7月, 2020 1 次提交
  16. 07 7月, 2020 1 次提交
    • B
      xfs: preserve rmapbt swapext block reservation from freed blocks · f74681ba
      Brian Foster 提交于
      The rmapbt extent swap algorithm remaps individual extents between
      the source inode and the target to trigger reverse mapping metadata
      updates. If either inode straddles a format or other bmap allocation
      boundary, the individual unmap and map cycles can trigger repeated
      bmap block allocations and frees as the extent count bounces back
      and forth across the boundary. While net block usage is bound across
      the swap operation, this behavior can prematurely exhaust the
      transaction block reservation because it continuously drains as the
      transaction rolls. Each allocation accounts against the reservation
      and each free returns to global free space on transaction roll.
      
      The previous workaround to this problem attempted to detect this
      boundary condition and provide surplus block reservation to
      acommodate it. This is insufficient because more remaps can occur
      than implied by the extent counts; if start offset boundaries are
      not aligned between the two inodes, for example.
      
      To address this problem more generically and dynamically, add a
      transaction accounting mode that returns freed blocks to the
      transaction reservation instead of the superblock counters on
      transaction roll and use it when the rmapbt based algorithm is
      active. This allows the chain of remap transactions to preserve the
      block reservation based own its own frees and prevent premature
      exhaustion regardless of the remap pattern. Note that this is only
      safe for superblocks with lazy sb accounting, but the latter is
      required for v5 supers and the rmap feature depends on v5.
      
      Fixes: b3fed434 ("xfs: account format bouncing into rmapbt swapext tx reservation")
      Root-caused-by: NDarrick J. Wong <darrick.wong@oracle.com>
      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>
      f74681ba
  17. 20 5月, 2020 3 次提交
  18. 07 5月, 2020 1 次提交
  19. 19 3月, 2020 1 次提交
  20. 03 3月, 2020 3 次提交
  21. 12 12月, 2019 1 次提交
    • B
      xfs: stabilize insert range start boundary to avoid COW writeback race · d0c22041
      Brian Foster 提交于
      generic/522 (fsx) occasionally fails with a file corruption due to
      an insert range operation. The primary characteristic of the
      corruption is a misplaced insert range operation that differs from
      the requested target offset. The reason for this behavior is a race
      between the extent shift sequence of an insert range and a COW
      writeback completion that causes a front merge with the first extent
      in the shift.
      
      The shift preparation function flushes and unmaps from the target
      offset of the operation to the end of the file to ensure no
      modifications can be made and page cache is invalidated before file
      data is shifted. An insert range operation then splits the extent at
      the target offset, if necessary, and begins to shift the start
      offset of each extent starting from the end of the file to the start
      offset. The shift sequence operates at extent level and so depends
      on the preparation sequence to guarantee no changes can be made to
      the target range during the shift. If the block immediately prior to
      the target offset was dirty and shared, however, it can undergo
      writeback and move from the COW fork to the data fork at any point
      during the shift. If the block is contiguous with the block at the
      start offset of the insert range, it can front merge and alter the
      start offset of the extent. Once the shift sequence reaches the
      target offset, it shifts based on the latest start offset and
      silently changes the target offset of the operation and corrupts the
      file.
      
      To address this problem, update the shift preparation code to
      stabilize the start boundary along with the full range of the
      insert. Also update the existing corruption check to fail if any
      extent is shifted with a start offset behind the target offset of
      the insert range. This prevents insert from racing with COW
      writeback completion and fails loudly in the event of an unexpected
      extent shift.
      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>
      d0c22041
  22. 12 11月, 2019 1 次提交