1. 29 6月, 2019 2 次提交
  2. 13 6月, 2019 1 次提交
  3. 12 6月, 2019 1 次提交
  4. 19 2月, 2019 1 次提交
  5. 12 2月, 2019 2 次提交
    • B
      xfs: distinguish between inobt and finobt magic values · 8473fee3
      Brian Foster 提交于
      The inode btree verifier code is shared between the inode btree and
      free inode btree because the underlying metadata formats are
      essentially equivalent. A side effect of this is that the verifier
      cannot determine whether a particular btree block should have an
      inobt or finobt magic value.
      
      This logic allows an unfortunate xfs_repair bug to escape detection
      where certain level > 0 nodes of the finobt are stamped with inobt
      magic by xfs_repair finobt reconstruction. This is fortunately not a
      severe problem since the inode btree magic values do not contribute
      to any changes in kernel behavior, but we do need a means to detect
      and prevent this problem in the future.
      
      Add a field to xfs_buf_ops to store the v4 and v5 superblock magic
      values expected by a particular verifier. Add a helper to check an
      on-disk magic value against the value expected by the verifier. Call
      the helper from the shared [f]inobt verifier code for magic value
      verification. This ensures that the inode btree blocks each have the
      appropriate magic value based on specific tree type and superblock
      version.
      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>
      8473fee3
    • B
      xfs: clarify documentation for the function to reverify buffers · 75d02303
      Brian Foster 提交于
      Improve the documentation around xfs_buf_ensure_ops, which is the
      function that is responsible for cleaning up the b_ops state of buffers
      that go through xrep_findroot_block but don't match anything.  Rename
      the function to xfs_buf_reverify.
      
      [darrick: this started off as bfoster mods of a previous patch of mine,
      but the renaming part is now this separate patch.]
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      75d02303
  6. 18 10月, 2018 1 次提交
  7. 12 8月, 2018 1 次提交
  8. 12 7月, 2018 2 次提交
  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. 16 5月, 2018 1 次提交
    • D
      xfs: one-shot cached buffers · 879de98e
      Dave Chinner 提交于
      For the new growfs work, we want to ensure that we serialise
      secondary superblock updates with other operations (e.g. scrub)
      correctly, but we don't want to cache the buffers for long term
      reuse. We need cached buffers for serialisation, however.
      
      To solve this, introduce a "oneshot" buffer which will be marshalled
      through the cache but then released once the last current reference
      goes away. If the buffer is already cached, then we ignore the
      "one-shot" behaviour and leave the buffer in the state it was prior
      to the one-shot command being run. This means we don't perturb
      either the working set or existing cached buffer state by a one-shot
      operation.
      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>
      879de98e
  11. 10 5月, 2018 1 次提交
  12. 10 4月, 2018 1 次提交
  13. 29 1月, 2018 2 次提交
  14. 09 1月, 2018 2 次提交
  15. 27 10月, 2017 1 次提交
    • B
      xfs: buffer lru reference count error injection tag · 7561d27e
      Brian Foster 提交于
      XFS uses a fixed reference count for certain types of buffers in the
      internal LRU cache. These reference counts dictate how aggressively
      certain buffers are reclaimed vs. others. While the reference counts
      implements priority across different buffer types, all buffers
      (other than uncached buffers) are typically cached for at least one
      reclaim cycle.
      
      We've had at least one bug recently that has been hidden by a
      released buffer sitting around in the LRU. Users hitting the problem
      were able to reproduce under enough memory pressure to cause
      aggressive reclaim in a particular window of time.
      
      To support future xfstests cases, add an error injection tag to
      hardcode the buffer reference count to zero. When enabled, this
      bypasses caching of associated buffers and facilitates test cases
      that depend on this behavior.
      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>
      7561d27e
  16. 01 9月, 2017 1 次提交
  17. 19 6月, 2017 1 次提交
    • B
      xfs: push buffer of flush locked dquot to avoid quotacheck deadlock · 7912e7fe
      Brian Foster 提交于
      Reclaim during quotacheck can lead to deadlocks on the dquot flush
      lock:
      
       - Quotacheck populates a local delwri queue with the physical dquot
         buffers.
       - Quotacheck performs the xfs_qm_dqusage_adjust() bulkstat and
         dirties all of the dquots.
       - Reclaim kicks in and attempts to flush a dquot whose buffer is
         already queud on the quotacheck queue. The flush succeeds but
         queueing to the reclaim delwri queue fails as the backing buffer is
         already queued. The flush unlock is now deferred to I/O completion
         of the buffer from the quotacheck queue.
       - The dqadjust bulkstat continues and dirties the recently flushed
         dquot once again.
       - Quotacheck proceeds to the xfs_qm_flush_one() walk which requires
         the flush lock to update the backing buffers with the in-core
         recalculated values. It deadlocks on the redirtied dquot as the
         flush lock was already acquired by reclaim, but the buffer resides
         on the local delwri queue which isn't submitted until the end of
         quotacheck.
      
      This is reproduced by running quotacheck on a filesystem with a
      couple million inodes in low memory (512MB-1GB) situations. This is
      a regression as of commit 43ff2122 ("xfs: on-stack delayed write
      buffer lists"), which removed a trylock and buffer I/O submission
      from the quotacheck dquot flush sequence.
      
      Quotacheck first resets and collects the physical dquot buffers in a
      delwri queue. Then, it traverses the filesystem inodes via bulkstat,
      updates the in-core dquots, flushes the corrected dquots to the
      backing buffers and finally submits the delwri queue for I/O. Since
      the backing buffers are queued across the entire quotacheck
      operation, dquot reclaim cannot possibly complete a dquot flush
      before quotacheck completes.
      
      Therefore, quotacheck must submit the buffer for I/O in order to
      cycle the flush lock and flush the dirty in-core dquot to the
      buffer. Add a delwri queue buffer push mechanism to submit an
      individual buffer for I/O without losing the delwri queue status and
      use it from quotacheck to avoid the deadlock. This restores
      quotacheck behavior to as before the regression was introduced.
      Reported-by: NMartin Svec <martin.svec@zoner.cz>
      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>
      7912e7fe
  18. 31 5月, 2017 1 次提交
    • B
      xfs: use ->b_state to fix buffer I/O accounting release race · 63db7c81
      Brian Foster 提交于
      We've had user reports of unmount hangs in xfs_wait_buftarg() that
      analysis shows is due to btp->bt_io_count == -1. bt_io_count
      represents the count of in-flight asynchronous buffers and thus
      should always be >= 0. xfs_wait_buftarg() waits for this value to
      stabilize to zero in order to ensure that all untracked (with
      respect to the lru) buffers have completed I/O processing before
      unmount proceeds to tear down in-core data structures.
      
      The value of -1 implies an I/O accounting decrement race. Indeed,
      the fact that xfs_buf_ioacct_dec() is called from xfs_buf_rele()
      (where the buffer lock is no longer held) means that bp->b_flags can
      be updated from an unsafe context. While a user-level reproducer is
      currently not available, some intrusive hacks to run racing buffer
      lookups/ioacct/releases from multiple threads was used to
      successfully manufacture this problem.
      
      Existing callers do not expect to acquire the buffer lock from
      xfs_buf_rele(). Therefore, we can not safely update ->b_flags from
      this context. It turns out that we already have separate buffer
      state bits and associated serialization for dealing with buffer LRU
      state in the form of ->b_state and ->b_lock. Therefore, replace the
      _XBF_IN_FLIGHT flag with a ->b_state variant, update the I/O
      accounting wrappers appropriately and make sure they are used with
      the correct locking. This ensures that buffer in-flight state can be
      modified at buffer release time without racing with modifications
      from a buffer lock holder.
      
      Fixes: 9c7504aa ("xfs: track and serialize in-flight async buffers against unmount")
      Cc: <stable@vger.kernel.org> # v4.8+
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NNikolay Borisov <nborisov@suse.com>
      Tested-by: NLibor Pechacek <lpechacek@suse.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      63db7c81
  19. 26 4月, 2017 1 次提交
  20. 04 4月, 2017 1 次提交
  21. 02 2月, 2017 1 次提交
  22. 07 12月, 2016 1 次提交
    • L
      xfs: use rhashtable to track buffer cache · 6031e73a
      Lucas Stach 提交于
      On filesystems with a lot of metadata and in metadata intensive workloads
      xfs_buf_find() is showing up at the top of the CPU cycles trace. Most of
      the CPU time is spent on CPU cache misses while traversing the rbtree.
      
      As the buffer cache does not need any kind of ordering, but fast lookups
      a hashtable is the natural data structure to use. The rhashtable
      infrastructure provides a self-scaling hashtable implementation and
      allows lookups to proceed while the table is going through a resize
      operation.
      
      This reduces the CPU-time spent for the lookups to 1/3 even for small
      filesystems with a relatively small number of cached buffers, with
      possibly much larger gains on higher loaded filesystems.
      
      [dchinner: reduce minimum hash size to an acceptable size for large
      	   filesystems with many AGs with no active use.]
      [dchinner: remove stale rbtree asserts.]
      [dchinner: use xfs_buf_map for compare function argument.]
      [dchinner: make functions static.]
      [dchinner: remove redundant comments.]
      Signed-off-by: NLucas Stach <dev@lynxeye.de>
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      
      6031e73a
  23. 28 11月, 2016 1 次提交
  24. 20 7月, 2016 2 次提交
    • B
      xfs: track and serialize in-flight async buffers against unmount · 9c7504aa
      Brian Foster 提交于
      Newly allocated XFS metadata buffers are added to the LRU once the hold
      count is released, which typically occurs after I/O completion. There is
      no other mechanism at current that tracks the existence or I/O state of
      a new buffer. Further, readahead I/O tends to be submitted
      asynchronously by nature, which means the I/O can remain in flight and
      actually complete long after the calling context is gone. This means
      that file descriptors or any other holds on the filesystem can be
      released, allowing the filesystem to be unmounted while I/O is still in
      flight. When I/O completion occurs, core data structures may have been
      freed, causing completion to run into invalid memory accesses and likely
      to panic.
      
      This problem is reproduced on XFS via directory readahead. A filesystem
      is mounted, a directory is opened/closed and the filesystem immediately
      unmounted. The open/close cycle triggers a directory readahead that if
      delayed long enough, runs buffer I/O completion after the unmount has
      completed.
      
      To address this problem, add a mechanism to track all in-flight,
      asynchronous buffers using per-cpu counters in the buftarg. The buffer
      is accounted on the first I/O submission after the current reference is
      acquired and unaccounted once the buffer is returned to the LRU or
      freed. Update xfs_wait_buftarg() to wait on all in-flight I/O before
      walking the LRU list. Once in-flight I/O has completed and the workqueue
      has drained, all new buffers should have been released onto the LRU.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      
      9c7504aa
    • B
      xfs: exclude never-released buffers from buftarg I/O accounting · c891c30a
      Brian Foster 提交于
      The upcoming buftarg I/O accounting mechanism maintains a count of
      all buffers that have undergone I/O in the current hold-release
      cycle.  Certain buffers associated with core infrastructure (e.g.,
      the xfs_mount superblock buffer, log buffers) are never released,
      however. This means that accounting I/O submission on such buffers
      elevates the buftarg count indefinitely and could lead to lockup on
      unmount.
      
      Define a new buffer flag to explicitly exclude buffers from buftarg
      I/O accounting. Set the flag on the superblock and associated log
      buffers.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      
      c891c30a
  25. 18 5月, 2016 2 次提交
  26. 10 2月, 2016 6 次提交
  27. 04 1月, 2016 1 次提交
  28. 09 9月, 2015 1 次提交
    • M
      dax: move DAX-related functions to a new header · c94c2acf
      Matthew Wilcox 提交于
      In order to handle the !CONFIG_TRANSPARENT_HUGEPAGES case, we need to
      return VM_FAULT_FALLBACK from the inlined dax_pmd_fault(), which is
      defined in linux/mm.h.  Given that we don't want to include <linux/mm.h>
      in <linux/fs.h>, the easiest solution is to move the DAX-related
      functions to a new header, <linux/dax.h>.  We could also have moved
      VM_FAULT_* definitions to a new header, or a different header that isn't
      quite such a boil-the-ocean header as <linux/mm.h>, but this felt like
      the best option.
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c94c2acf
反馈
建议
客服 返回
顶部