1. 18 1月, 2022 2 次提交
    • D
      xfs: remove the XFS_IOC_{ALLOC,FREE}SP* definitions · b3bb9413
      Darrick J. Wong 提交于
      Now that we've made these ioctls defunct, move them from xfs_fs.h to
      xfs_ioctl.c, which effectively removes them from the publicly supported
      ioctl interfaces for XFS.
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NEric Sandeen <sandeen@redhat.com>
      b3bb9413
    • 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. 22 12月, 2021 1 次提交
  3. 21 10月, 2021 1 次提交
  4. 12 10月, 2021 1 次提交
  5. 20 8月, 2021 5 次提交
  6. 07 8月, 2021 1 次提交
  7. 16 7月, 2021 2 次提交
    • D
      xfs: don't expose misaligned extszinherit hints to userspace · 5aa5b278
      Darrick J. Wong 提交于
      Commit 603f000b changed xfs_ioctl_setattr_check_extsize to reject an
      attempt to set an EXTSZINHERIT extent size hint on a directory with
      RTINHERIT set if the hint isn't a multiple of the realtime extent size.
      However, I have recently discovered that it is possible to change the
      realtime extent size when adding a rt device to a filesystem, which
      means that the existence of directories with misaligned inherited hints
      is not an accident.
      
      As a result, it's possible that someone could have set a valid hint and
      added an rt volume with a different rt extent size, which invalidates
      the ondisk hints.  After such a sequence, FSGETXATTR will report a
      misaligned hint, which FSSETXATTR will trip over, causing confusion if
      the user was doing the usual GET/SET sequence to change some other
      attribute.  Change xfs_fill_fsxattr to omit the hint if it isn't aligned
      properly.
      
      Fixes: 603f000b ("xfs: validate extsz hints against rt extent size when rtinherit is set")
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      5aa5b278
    • D
      xfs: correct the narrative around misaligned rtinherit/extszinherit dirs · 83193e5e
      Darrick J. Wong 提交于
      While auditing the realtime growfs code, I realized that the GROWFSRT
      ioctl (and by extension xfs_growfs) has always allowed sysadmins to
      change the realtime extent size when adding a realtime section to the
      filesystem.  Since we also have always allowed sysadmins to set
      RTINHERIT and EXTSZINHERIT on directories even if there is no realtime
      device, this invalidates the premise laid out in the comments added in
      commit 603f000b.
      
      In other words, this is not a case of inadequate metadata validation.
      This is a case of nearly forgotten (and apparently untested) but
      supported functionality.  Update the comments to reflect what we've
      learned, and remove the log message about correcting the misalignment.
      
      Fixes: 603f000b ("xfs: validate extsz hints against rt extent size when rtinherit is set")
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      83193e5e
  8. 09 6月, 2021 2 次提交
  9. 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
  10. 25 5月, 2021 2 次提交
    • D
      xfs: validate extsz hints against rt extent size when rtinherit is set · 603f000b
      Darrick J. Wong 提交于
      The RTINHERIT bit can be set on a directory so that newly created
      regular files will have the REALTIME bit set to store their data on the
      realtime volume.  If an extent size hint (and EXTSZINHERIT) are set on
      the directory, the hint will also be copied into the new file.
      
      As pointed out in previous patches, for realtime files we require the
      extent size hint be an integer multiple of the realtime extent, but we
      don't perform the same validation on a directory with both RTINHERIT and
      EXTSZINHERIT set, even though the only use-case of that combination is
      to propagate extent size hints into new realtime files.  This leads to
      inode corruption errors when the bad values are propagated.
      
      Because there may be existing filesystems with such a configuration, we
      cannot simply amend the inode verifier to trip on these directories and
      call it a day because that will cause previously "working" filesystems
      to start throwing errors abruptly.  Note that it's valid to have
      directories with rtinherit set even if there is no realtime volume, in
      which case the problem does not manifest because rtinherit is ignored if
      there's no realtime device; and it's possible that someone set the flag,
      crashed, repaired the filesystem (which clears the hint on the realtime
      file) and continued.
      
      Therefore, mitigate this issue in several ways: First, if we try to
      write out an inode with both rtinherit/extszinherit set and an unaligned
      extent size hint, turn off the hint to correct the error.  Second, if
      someone tries to misconfigure a directory via the fssetxattr ioctl, fail
      the ioctl.  Third, reverify both extent size hint values when we
      propagate heritable inode attributes from parent to child, to prevent
      misconfigurations from spreading.
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      603f000b
    • D
      xfs: standardize extent size hint validation · 6b69e485
      Darrick J. Wong 提交于
      While chasing a bug involving invalid extent size hints being propagated
      into newly created realtime files, I noticed that the xfs_ioctl_setattr
      checks for the extent size hints weren't the same as the ones now
      encoded in libxfs and used for validation in repair and mkfs.
      
      Because the checks in libxfs are more stringent than the ones in the
      ioctl, it's possible for a live system to set inode flags that
      immediately result in corruption warnings.  Specifically, it's possible
      to set an extent size hint on an rtinherit directory without checking if
      the hint is aligned to the realtime extent size, which makes no sense
      since that combination is used only to seed new realtime files.
      
      Replace the open-coded and inadequate checks with the libxfs verifier
      versions and update the code comments a bit.
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      6b69e485
  11. 16 4月, 2021 1 次提交
  12. 12 4月, 2021 1 次提交
  13. 10 4月, 2021 1 次提交
    • D
      xfs: fix scrub and remount-ro protection when running scrub · 71bddbcc
      Darrick J. Wong 提交于
      While running a new fstest that races a readonly remount with scrub
      running in repair mode, I observed the kernel tripping over debugging
      assertions in the log quiesce code that were checking that the CIL was
      empty.  When the sysadmin runs scrub in repair mode, the scrub code
      allocates real transactions (with reservations) to change things, but
      doesn't increment the superblock writers count to block a readonly
      remount attempt while it is running.
      
      We don't require the userspace caller to have a writable file descriptor
      to run repairs, so we have to call mnt_want_write_file to obtain freeze
      protection and increment the writers count.  It's ok to remove the call
      to sb_start_write for the dry-run case because commit 8321ddb2
      removed the behavior where scrub and fsfreeze fight over the buffer LRU.
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NChandan Babu R <chandanrlinux@gmail.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      71bddbcc
  14. 08 4月, 2021 9 次提交
  15. 04 2月, 2021 5 次提交
  16. 24 1月, 2021 3 次提交
  17. 07 10月, 2020 1 次提交
    • D
      xfs: fix deadlock and streamline xfs_getfsmap performance · 8ffa90e1
      Darrick J. Wong 提交于
      Refactor xfs_getfsmap to improve its performance: instead of indirectly
      calling a function that copies one record to userspace at a time, create
      a shadow buffer in the kernel and copy the whole array once at the end.
      On the author's computer, this reduces the runtime on his /home by ~20%.
      
      This also eliminates a deadlock when running GETFSMAP against the
      realtime device.  The current code locks the rtbitmap to create
      fsmappings and copies them into userspace, having not released the
      rtbitmap lock.  If the userspace buffer is an mmap of a sparse file that
      itself resides on the realtime device, the write page fault will recurse
      into the fs for allocation, which will deadlock on the rtbitmap lock.
      
      Fixes: 4c934c7d ("xfs: report realtime space information via the rtbitmap")
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NChandan Babu R <chandanrlinux@gmail.com>
      8ffa90e1
  18. 16 9月, 2020 1 次提交