1. 09 6月, 2021 1 次提交
  2. 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
  3. 16 4月, 2021 1 次提交
  4. 12 4月, 2021 1 次提交
  5. 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
  6. 08 4月, 2021 9 次提交
  7. 04 2月, 2021 5 次提交
  8. 24 1月, 2021 3 次提交
  9. 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
  10. 16 9月, 2020 2 次提交
  11. 29 7月, 2020 1 次提交
  12. 30 5月, 2020 2 次提交
  13. 27 5月, 2020 1 次提交
  14. 20 5月, 2020 1 次提交
  15. 05 5月, 2020 2 次提交
  16. 13 4月, 2020 1 次提交
  17. 19 3月, 2020 2 次提交
  18. 03 3月, 2020 4 次提交