1. 20 8月, 2021 2 次提交
    • D
      xfs: convert xfs_sb_version_has checks to use mount features · ebd9027d
      Dave Chinner 提交于
      This is a conversion of the remaining xfs_sb_version_has..(sbp)
      checks to use xfs_has_..(mp) feature checks.
      
      This was largely done with a vim replacement macro that did:
      
      :0,$s/xfs_sb_version_has\(.*\)&\(.*\)->m_sb/xfs_has_\1\2/g<CR>
      
      A couple of other variants were also used, and the rest touched up
      by hand.
      
      $ size -t fs/xfs/built-in.a
      	   text    data     bss     dec     hex filename
      before	1127533  311352     484 1439369  15f689 (TOTALS)
      after	1125360  311352     484 1437196  15ee0c (TOTALS)
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      ebd9027d
    • D
      xfs: replace xfs_sb_version checks with feature flag checks · 38c26bfd
      Dave Chinner 提交于
      Convert the xfs_sb_version_hasfoo() to checks against
      mp->m_features. Checks of the superblock itself during disk
      operations (e.g. in the read/write verifiers and the to/from disk
      formatters) are not converted - they operate purely on the
      superblock state. Everything else should use the mount features.
      
      Large parts of this conversion were done with sed with commands like
      this:
      
      for f in `git grep -l xfs_sb_version_has fs/xfs/*.c`; do
      	sed -i -e 's/xfs_sb_version_has\(.*\)(&\(.*\)->m_sb)/xfs_has_\1(\2)/' $f
      done
      
      With manual cleanups for things like "xfs_has_extflgbit" and other
      little inconsistencies in naming.
      
      The result is ia lot less typing to check features and an XFS binary
      size reduced by a bit over 3kB:
      
      $ size -t fs/xfs/built-in.a
      	text	   data	    bss	    dec	    hex	filenam
      before	1130866  311352     484 1442702  16038e (TOTALS)
      after	1127727  311352     484 1439563  15f74b (TOTALS)
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      38c26bfd
  2. 26 3月, 2021 1 次提交
    • D
      xfs: No need for inode number error injection in __xfs_dir3_data_check · 39d3c0b5
      Dave Chinner 提交于
      We call xfs_dir_ino_validate() for every dir entry in a directory
      when doing validity checking of the directory. It calls
      xfs_verify_dir_ino() then emits a corruption report if bad or does
      error injection if good. It is extremely costly:
      
        43.27%  [kernel]  [k] xfs_dir3_leaf_check_int
        10.28%  [kernel]  [k] __xfs_dir3_data_check
         6.61%  [kernel]  [k] xfs_verify_dir_ino
         4.16%  [kernel]  [k] xfs_errortag_test
         4.00%  [kernel]  [k] memcpy
         3.48%  [kernel]  [k] xfs_dir_ino_validate
      
      7% of the cpu usage in this directory traversal workload is
      xfs_dir_ino_validate() doing absolutely nothing.
      
      We don't need error injection to simulate a bad inode numbers in the
      directory structure because we can do that by fuzzing the structure
      on disk.
      
      And we don't need a corruption report, because the
      __xfs_dir3_data_check() will emit one if the inode number is bad.
      
      So just call xfs_verify_dir_ino() directly here, and get rid of all
      this unnecessary overhead:
      
        40.30%  [kernel]  [k] xfs_dir3_leaf_check_int
        10.98%  [kernel]  [k] __xfs_dir3_data_check
         8.10%  [kernel]  [k] xfs_verify_dir_ino
         4.42%  [kernel]  [k] memcpy
         2.22%  [kernel]  [k] xfs_dir2_data_get_ftype
         1.52%  [kernel]  [k] do_raw_spin_lock
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      39d3c0b5
  3. 12 3月, 2020 1 次提交
  4. 23 11月, 2019 3 次提交
  5. 14 11月, 2019 2 次提交
  6. 11 11月, 2019 10 次提交
  7. 29 6月, 2019 3 次提交
  8. 12 2月, 2019 1 次提交
  9. 07 6月, 2018 1 次提交
    • D
      xfs: convert to SPDX license tags · 0b61f8a4
      Dave Chinner 提交于
      Remove the verbose license text from XFS files and replace them
      with SPDX tags. This does not change the license of any of the code,
      merely refers to the common, up-to-date license files in LICENSES/
      
      This change was mostly scripted. fs/xfs/Makefile and
      fs/xfs/libxfs/xfs_fs.h were modified by hand, the rest were detected
      and modified by the following command:
      
      for f in `git grep -l "GNU General" fs/xfs/` ; do
      	echo $f
      	cat $f | awk -f hdr.awk > $f.new
      	mv -f $f.new $f
      done
      
      And the hdr.awk script that did the modification (including
      detecting the difference between GPL-2.0 and GPL-2.0+ licenses)
      is as follows:
      
      $ cat hdr.awk
      BEGIN {
      	hdr = 1.0
      	tag = "GPL-2.0"
      	str = ""
      }
      
      /^ \* This program is free software/ {
      	hdr = 2.0;
      	next
      }
      
      /any later version./ {
      	tag = "GPL-2.0+"
      	next
      }
      
      /^ \*\// {
      	if (hdr > 0.0) {
      		print "// SPDX-License-Identifier: " tag
      		print str
      		print $0
      		str=""
      		hdr = 0.0
      		next
      	}
      	print $0
      	next
      }
      
      /^ \* / {
      	if (hdr > 1.0)
      		next
      	if (hdr > 0.0) {
      		if (str != "")
      			str = str "\n"
      		str = str $0
      		next
      	}
      	print $0
      	next
      }
      
      /^ \*/ {
      	if (hdr > 0.0)
      		next
      	print $0
      	next
      }
      
      // {
      	if (hdr > 0.0) {
      		if (str != "")
      			str = str "\n"
      		str = str $0
      		next
      	}
      	print $0
      }
      
      END { }
      $
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      0b61f8a4
  10. 05 6月, 2018 2 次提交
  11. 24 3月, 2018 1 次提交
  12. 29 1月, 2018 1 次提交
    • C
      Split buffer's b_fspriv field · fb1755a6
      Carlos Maiolino 提交于
      By splitting the b_fspriv field into two different fields (b_log_item
      and b_li_list). It's possible to get rid of an old ABI workaround, by
      using the new b_log_item field to store xfs_buf_log_item separated from
      the log items attached to the buffer, which will be linked in the new
      b_li_list field.
      
      This way, there is no more need to reorder the log items list to place
      the buf_log_item at the beginning of the list, simplifying a bit the
      logic to handle buffer IO.
      
      This also opens the possibility to change buffer's log items list into a
      proper list_head.
      
      b_log_item field is still defined as a void *, because it is still used
      by the log buffers to store xlog_in_core structures, and there is no
      need to add an extra field on xfs_buf just for xlog_in_core.
      Signed-off-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Reviewed-by: NBill O'Donnell <billodo@redhat.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      [darrick: minor style changes]
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      fb1755a6
  13. 18 1月, 2018 1 次提交
  14. 10 1月, 2018 1 次提交
    • D
      xfs: harden directory integrity checks some more · 46c59736
      Darrick J. Wong 提交于
      If a malicious filesystem image contains a block+ format directory
      wherein the directory inode's core.mode is set such that
      S_ISDIR(core.mode) == 0, and if there are subdirectories of the
      corrupted directory, an attempt to traverse up the directory tree will
      crash the kernel in __xfs_dir3_data_check.  Running the online scrub's
      parent checks will tend to do this.
      
      The crash occurs because the directory inode's d_ops get set to
      xfs_dir[23]_nondir_ops (it's not a directory) but the parent pointer
      scrubber's indiscriminate call to xfs_readdir proceeds past the ASSERT
      if we have non fatal asserts configured.
      
      Fix the null pointer dereference crash in __xfs_dir3_data_check by
      looking for S_ISDIR or wrong d_ops; and teach the parent scrubber
      to bail out if it is fed a non-directory "parent".
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      46c59736
  15. 09 1月, 2018 5 次提交
  16. 25 7月, 2017 1 次提交
  17. 05 12月, 2016 1 次提交
  18. 08 11月, 2016 1 次提交
  19. 04 1月, 2016 1 次提交
  20. 12 10月, 2015 1 次提交
    • B
      xfs: validate metadata LSNs against log on v5 superblocks · a45086e2
      Brian Foster 提交于
      Since the onset of v5 superblocks, the LSN of the last modification has
      been included in a variety of on-disk data structures. This LSN is used
      to provide log recovery ordering guarantees (e.g., to ensure an older
      log recovery item is not replayed over a newer target data structure).
      
      While this works correctly from the point a filesystem is formatted and
      mounted, userspace tools have some problematic behaviors that defeat
      this mechanism. For example, xfs_repair historically zeroes out the log
      unconditionally (regardless of whether corruption is detected). If this
      occurs, the LSN of the filesystem is reset and the log is now in a
      problematic state with respect to on-disk metadata structures that might
      have a larger LSN. Until either the log catches up to the highest
      previously used metadata LSN or each affected data structure is modified
      and written out without incident (which resets the metadata LSN), log
      recovery is susceptible to filesystem corruption.
      
      This problem is ultimately addressed and repaired in the associated
      userspace tools. The kernel is still responsible to detect the problem
      and notify the user that something is wrong. Check the superblock LSN at
      mount time and fail the mount if it is invalid. From that point on,
      trigger verifier failure on any metadata I/O where an invalid LSN is
      detected. This results in a filesystem shutdown and guarantees that we
      do not log metadata changes with invalid LSNs on disk. Since this is a
      known issue with a known recovery path, present a warning to instruct
      the user how to recover.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      a45086e2