An error occurred fetching the project authors.
  1. 22 Apr, 2024 1 commit
  2. 22 Feb, 2024 1 commit
  3. 19 Feb, 2024 1 commit
  4. 30 Jan, 2024 1 commit
    • Darrick J. Wong's avatar
      xfs: remove conditional building of rt geometry validator functions · 881f78f4
      Darrick J. Wong authored
      I mistakenly turned off CONFIG_XFS_RT in the Kconfig file for arm64
      variant of the djwong-wtf git branch.  Unfortunately, it took me a good
      hour to figure out that RT wasn't built because this is what got printed
      to dmesg:
      
      XFS (sda2): realtime geometry sanity check failed
      XFS (sda2): Metadata corruption detected at xfs_sb_read_verify+0x170/0x190 [xfs], xfs_sb block 0x0
      
      Whereas I would have expected:
      
      XFS (sda2): Not built with CONFIG_XFS_RT
      XFS (sda2): RT mount failed
      
      The root cause of these problems is the conditional compilation of the
      new functions xfs_validate_rtextents and xfs_compute_rextslog that I
      introduced in the two commits listed below.  The !RT versions of these
      functions return false and 0, respectively, which causes primary
      superblock validation to fail, which explains the first message.
      
      Move the two functions to other parts of libxfs that are not
      conditionally defined by CONFIG_XFS_RT and remove the broken stubs so
      that validation works again.
      
      Fixes: e1429380 ("xfs: don't allow overly small or large realtime volumes")
      Fixes: a6a38f30 ("xfs: make rextslog computation consistent with mkfs")
      Signed-off-by: default avatar"Darrick J. Wong" <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarChandan Babu R <chandanbabu@kernel.org>
      881f78f4
  5. 22 Dec, 2023 4 commits
  6. 07 Dec, 2023 2 commits
    • Darrick J. Wong's avatar
      xfs: fix 32-bit truncation in xfs_compute_rextslog · cf8f0e6c
      Darrick J. Wong authored
      It's quite reasonable that some customer somewhere will want to
      configure a realtime volume with more than 2^32 extents.  If they try to
      do this, the highbit32() call will truncate the upper bits of the
      xfs_rtbxlen_t and produce the wrong value for rextslog.  This in turn
      causes the rsumlevels to be wrong, which results in a realtime summary
      file that is the wrong length.  Fix that.
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      cf8f0e6c
    • Darrick J. Wong's avatar
      xfs: make rextslog computation consistent with mkfs · a6a38f30
      Darrick J. Wong authored
      There's a weird discrepancy in xfsprogs dating back to the creation of
      the Linux port -- if there are zero rt extents, mkfs will set
      sb_rextents and sb_rextslog both to zero:
      
      	sbp->sb_rextslog =
      		(uint8_t)(rtextents ?
      			libxfs_highbit32((unsigned int)rtextents) : 0);
      
      However, that's not the check that xfs_repair uses for nonzero rtblocks:
      
      	if (sb->sb_rextslog !=
      			libxfs_highbit32((unsigned int)sb->sb_rextents))
      
      The difference here is that xfs_highbit32 returns -1 if its argument is
      zero.  Unfortunately, this means that in the weird corner case of a
      realtime volume shorter than 1 rt extent, xfs_repair will immediately
      flag a freshly formatted filesystem as corrupt.  Because mkfs has been
      writing ondisk artifacts like this for decades, we have to accept that
      as "correct".  TBH, zero rextslog for zero rtextents makes more sense to
      me anyway.
      
      Regrettably, the superblock verifier checks created in commit copied
      xfs_repair even though mkfs has been writing out such filesystems for
      ages.  Fix the superblock verifier to accept what mkfs spits out; the
      userspace version of this patch will have to fix xfs_repair as well.
      
      Note that the new helper leaves the zeroday bug where the upper 32 bits
      of sb_rextents is ripped off and fed to highbit32.  This leads to a
      seriously undersized rt summary file, which immediately breaks mkfs:
      
      $ hugedisk.sh foo /dev/sdc $(( 0x100000080 * 4096))B
      $ /sbin/mkfs.xfs -f /dev/sda -m rmapbt=0,reflink=0 -r rtdev=/dev/mapper/foo
      meta-data=/dev/sda               isize=512    agcount=4, agsize=1298176 blks
               =                       sectsz=512   attr=2, projid32bit=1
               =                       crc=1        finobt=1, sparse=1, rmapbt=0
               =                       reflink=0    bigtime=1 inobtcount=1 nrext64=1
      data     =                       bsize=4096   blocks=5192704, imaxpct=25
               =                       sunit=0      swidth=0 blks
      naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
      log      =internal log           bsize=4096   blocks=16384, version=2
               =                       sectsz=512   sunit=0 blks, lazy-count=1
      realtime =/dev/mapper/foo        extsz=4096   blocks=4294967424, rtextents=4294967424
      Discarding blocks...Done.
      mkfs.xfs: Error initializing the realtime space [117 - Structure needs cleaning]
      
      The next patch will drop support for rt volumes with fewer than 1 or
      more than 2^32-1 rt extents, since they've clearly been broken forever.
      
      Fixes: f8e566c0 ("xfs: validate the realtime geometry in xfs_validate_sb_common")
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      a6a38f30
  7. 19 Oct, 2023 4 commits
    • Omar Sandoval's avatar
      xfs: invert the realtime summary cache · e23aaf45
      Omar Sandoval authored
      In commit 355e3532 ("xfs: cache minimum realtime summary level"), I
      added a cache of the minimum level of the realtime summary that has any
      free extents. However, it turns out that the _maximum_ level is more
      useful for upcoming optimizations, and basically equivalent for the
      existing usage. So, let's change the meaning of the cache to be the
      maximum level + 1, or 0 if there are no free extents.
      
      For example, if the cache contains:
      
      {0, 4}
      
      then there are no free extents starting in realtime bitmap block 0, and
      there are no free extents larger than or equal to 2^4 blocks starting in
      realtime bitmap block 1. The cache is a loose upper bound, so there may
      or may not be free extents smaller than 2^4 blocks in realtime bitmap
      block 1.
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      e23aaf45
    • Darrick J. Wong's avatar
      xfs: simplify rt bitmap/summary block accessor functions · e2cf427c
      Darrick J. Wong authored
      Simplify the calling convention of these functions since the
      xfs_rtalloc_args structure contains the parameters we need.
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      e2cf427c
    • Darrick J. Wong's avatar
      xfs: simplify xfs_rtbuf_get calling conventions · 5b1d0ae9
      Darrick J. Wong authored
      Now that xfs_rtalloc_args holds references to the last-read bitmap and
      summary blocks, we don't need to pass the buffer pointer out of
      xfs_rtbuf_get.
      
      Callers no longer have to xfs_trans_brelse on their own, though they are
      required to call xfs_rtbuf_cache_relse before the xfs_rtalloc_args goes
      out of scope.
      
      While we're at it, create some trivial helpers so that we don't have to
      remember if "0" means "bitmap" and "1" means "summary".
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      5b1d0ae9
    • Omar Sandoval's avatar
      xfs: cache last bitmap block in realtime allocator · e94b53ff
      Omar Sandoval authored
      Profiling a workload on a highly fragmented realtime device showed a ton
      of CPU cycles being spent in xfs_trans_read_buf() called by
      xfs_rtbuf_get(). Further tracing showed that much of that was repeated
      calls to xfs_rtbuf_get() for the same block of the realtime bitmap.
      These come from xfs_rtallocate_extent_block(): as it walks through
      ranges of free bits in the bitmap, each call to xfs_rtcheck_range() and
      xfs_rtfind_{forw,back}() gets the same bitmap block. If the bitmap block
      is very fragmented, then this is _a lot_ of buffer lookups.
      
      The realtime allocator already passes around a cache of the last used
      realtime summary block to avoid repeated reads (the parameters rbpp and
      rsb). We can do the same for the realtime bitmap.
      
      This replaces rbpp and rsb with a struct xfs_rtbuf_cache, which caches
      the most recently used block for both the realtime bitmap and summary.
      xfs_rtbuf_get() now handles the caching instead of the callers, which
      requires plumbing xfs_rtbuf_cache to more functions but also makes sure
      we don't miss anything.
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      e94b53ff
  8. 18 Oct, 2023 10 commits
  9. 17 Oct, 2023 7 commits
  10. 11 Apr, 2022 1 commit
  11. 19 Aug, 2021 1 commit
    • Darrick J. Wong's avatar
      xfs: make xfs_rtalloc_query_range input parameters const · c02f6529
      Darrick J. Wong authored
      In commit 8ad560d2, we changed xfs_rtalloc_query_range to constrain
      the range of bits in the realtime bitmap file that would actually be
      searched.  In commit a3a374bf, we changed the range again
      (incorrectly), leading to the fix in commit d88850bd, which finally
      corrected the range check code.  Unfortunately, the author never noticed
      that the function modifies its input parameters, which is a totaly no-no
      since none of the other range query functions change their input
      parameters.
      
      So, fix this function yet again to stash the upper end of the query
      range (i.e. the high key) in a local variable and hope this is the last
      time I have to fix my own function.  While we're at it, mark the key
      inputs const so nobody makes this mistake again. :(
      
      Fixes: 8ad560d2 ("xfs: strengthen rtalloc query range checks")
      Not-fixed-by: a3a374bf ("xfs: fix off-by-one error in xfs_rtalloc_query_range")
      Not-fixed-by: d88850bd ("xfs: fix high key handling in the rt allocator's query_range function")
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarChandan Babu R <chandanrlinux@gmail.com>
      c02f6529
  12. 07 Apr, 2021 1 commit
  13. 17 Dec, 2020 1 commit
  14. 16 Oct, 2020 1 commit
    • Darrick J. Wong's avatar
      xfs: fix high key handling in the rt allocator's query_range function · d88850bd
      Darrick J. Wong authored
      Fix some off-by-one errors in xfs_rtalloc_query_range.  The highest key
      in the realtime bitmap is always one less than the number of rt extents,
      which means that the key clamp at the start of the function is wrong.
      The 4th argument to xfs_rtfind_forw is the highest rt extent that we
      want to probe, which means that passing 1 less than the high key is
      wrong.  Finally, drop the rem variable that controls the loop because we
      can compare the iteration point (rtstart) against the high key directly.
      
      The sordid history of this function is that the original commit (fb3c3)
      incorrectly passed (high_rec->ar_startblock - 1) as the 'limit' parameter
      to xfs_rtfind_forw.  This was wrong because the "high key" is supposed
      to be the largest key for which the caller wants result rows, not the
      key for the first row that could possibly be outside the range that the
      caller wants to see.
      
      A subsequent attempt (8ad56) to strengthen the parameter checking added
      incorrect clamping of the parameters to the number of rt blocks in the
      system (despite the bitmap functions all taking units of rt extents) to
      avoid querying ranges past the end of rt bitmap file but failed to fix
      the incorrect _rtfind_forw parameter.  The original _rtfind_forw
      parameter error then survived the conversion of the startblock and
      blockcount fields to rt extents (a0e5c), and the most recent off-by-one
      fix (a3a37) thought it was patching a problem when the end of the rt
      volume is not in use, but none of these fixes actually solved the
      original problem that the author was confused about the "limit" argument
      to xfs_rtfind_forw.
      
      Sadly, all four of these patches were written by this author and even
      his own usage of this function and rt testing were inadequate to get
      this fixed quickly.
      
      Original-problem: fb3c3de2 ("xfs: add a couple of queries to iterate free extents in the rtbitmap")
      Not-fixed-by: 8ad560d2 ("xfs: strengthen rtalloc query range checks")
      Not-fixed-by: a0e5c435 ("xfs: fix xfs_rtalloc_rec units")
      Fixes: a3a374bf ("xfs: fix off-by-one error in xfs_rtalloc_query_range")
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarChandan Babu R <chandanrlinux@gmail.com>
      d88850bd
  15. 06 Jul, 2020 1 commit
  16. 19 May, 2020 1 commit
  17. 13 Nov, 2019 1 commit
  18. 04 Nov, 2019 1 commit