1. 16 Apr, 2019 2 commits
  2. 15 Apr, 2019 13 commits
    • Darrick J. Wong's avatar
      xfs: report inode health via bulkstat · 89d139d5
      Darrick J. Wong authored
      Use space in the bulkstat ioctl structure to report any problems
      observed with the inode.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      89d139d5
    • Darrick J. Wong's avatar
      xfs: report AG health via AG geometry ioctl · 1302c6a2
      Darrick J. Wong authored
      Use the AG geometry info ioctl to report health status too.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      1302c6a2
    • Darrick J. Wong's avatar
      xfs: report fs and rt health via geometry structure · c23232d4
      Darrick J. Wong authored
      Use our newly expanded geometry structure to report the overall fs and
      realtime health status.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      c23232d4
    • Darrick J. Wong's avatar
      xfs: add a new ioctl to describe allocation group geometry · 7cd5006b
      Darrick J. Wong authored
      Add a new ioctl to describe an allocation group's geometry.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      7cd5006b
    • Dave Chinner's avatar
      xfs: bump XFS_IOC_FSGEOMETRY to v5 structures · 1b6d968d
      Dave Chinner authored
      Unfortunately, the V4 XFS_IOC_FSGEOMETRY structure is out of space so we
      can't just add a new field to it. Hence we need to bump the definition
      to V5 and and treat the V4 ioctl and structure similar to v1 to v3.
      
      While doing this, clean up all the definitions associated with the
      XFS_IOC_FSGEOMETRY ioctl.
      Signed-Off-By: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      [darrick: forward port to 5.1, expand structure size to 256 bytes]
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      1b6d968d
    • Darrick J. Wong's avatar
      xfs: clear BAD_SUMMARY if unmounting an unhealthy filesystem · 519841c2
      Darrick J. Wong authored
      If we know the filesystem metadata isn't healthy during unmount, we want
      to encourage the administrator to run xfs_repair right away.  We can't
      do this if BAD_SUMMARY will cause an unclean log unmount to force
      summary recalculation, so turn it off if the fs is bad.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      519841c2
    • Darrick J. Wong's avatar
      xfs: replace the BAD_SUMMARY mount flag with the equivalent health code · 39353ff6
      Darrick J. Wong authored
      Replace the BAD_SUMMARY mount flag with calls to the equivalent health
      tracking code.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      39353ff6
    • Darrick J. Wong's avatar
      xfs: track metadata health status · 6772c1f1
      Darrick J. Wong authored
      Add the necessary in-core metadata fields to keep track of which parts
      of the filesystem have been observed and which parts were observed to be
      unhealthy, and print a warning at unmount time if we have unfixed
      problems.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      6772c1f1
    • Wang Shilong's avatar
      xfs,fstrim: fix to return correct minlen · 2bf9d264
      Wang Shilong authored
      This patch tries to address two problems:
      
      1) return @minlen we used to trim to
      user space.
      
      2) return EINVAL if granularity is larger than
      avg size, even most of cases, granularity is small(4K),
      but if devices return a lager granularity for some reaons
      (testing, bugs etc), fstrim should return failure directly.
      Signed-off-by: default avatarWang Shilong <wshilong@ddn.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      2bf9d264
    • Brian Foster's avatar
      xfs: don't account extra agfl blocks as available · 1ca89fbc
      Brian Foster authored
      The block allocation AG selection code has parameters that allow a
      caller to perform multiple allocations from a single AG and
      transaction (under certain conditions). The parameters specify the
      total block allocation count required by the transaction and the AG
      selection code selects and locks an AG that will be able to satisfy
      the overall requirement. If the available block accounting
      calculation turns out to be inaccurate and a subsequent allocation
      call fails with -ENOSPC, the resulting transaction cancel leads to
      filesystem shutdown because the transaction is dirty.
      
      This exact problem can be reproduced with a highly parallel space
      consumer and fsstress workload running long enough to a large
      filesystem against -ENOSPC conditions. A bmbt block allocation
      request made for inode extent to bmap format conversion after an
      extent allocation is expected to be satisfied by the same AG and the
      same transaction as the extent allocation. The bmbt block allocation
      fails, however, because the block availability of the AG has changed
      since the AG was selected (outside of the blocks used for the extent
      itself).
      
      The inconsistent block availability calculation is caused by the
      deferred block freeing behavior of the AGFL. This immediately
      removes extra blocks from the AGFL to free up AGFL slots, but rather
      than immediately freeing such blocks as was done in the past, the
      block free is deferred such that said blocks are not available for
      allocation until the current transaction commits. The AG selection
      logic currently considers all AGFL blocks as available and executes
      shortly before any extra AGFL blocks are freed. This means the block
      availability of the current AG can change before the first
      allocation even occurs, but in practice a failure is more likely to
      manifest via a subsequent allocation because extent allocation
      usually has a contiguity requirement larger than a single block that
      can't be satisfied from the AGFL.
      
      In general, XFS prefers operational robustness to absolute
      allocation efficiency. In other words, we prefer to return -ENOSPC
      slightly earlier at the expense of not being able to allocate every
      last block in an AG to avoid this kind of problem. As such, update
      the AG block availability calculation to consider extra AGFL blocks
      as unavailable since they are immediately removed following the
      calculation and will not become available until the current
      transaction commits.
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      1ca89fbc
    • Brian Foster's avatar
      xfs: shutdown after buf release in iflush cluster abort path · 22fedd80
      Brian Foster authored
      If xfs_iflush_cluster() fails due to corruption, the error path
      issues a shutdown and simulates an I/O completion to release the
      buffer. This code has a couple small problems. First, the shutdown
      sequence can issue a synchronous log force, which is unsafe to do
      with buffer locks held. Second, the simulated I/O completion does not
      guarantee the buffer is async and thus is unlocked and released.
      
      For example, if the last operation on the buffer was a read off disk
      prior to the corruption event, XBF_ASYNC is not set and the buffer
      is left locked and held upon return. This results in a memory leak
      as shown by the following message on module unload:
      
       BUG xfs_buf (...): Objects remaining in xfs_buf on __kmem_cache_shutdown()
      
      Fix both of these problems by setting XBF_ASYNC on the buffer prior
      to the simulated I/O error and performing the shutdown immediately
      after ioend processing when the buffer has been released.
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      22fedd80
    • Brian Foster's avatar
      xfs: wake commit waiters on CIL abort before log item abort · 545aa41f
      Brian Foster authored
      XFS shutdown deadlocks have been reproduced by fstest generic/475.
      The deadlock signature involves log I/O completion running error
      handling to abort logged items and waiting for an inode cluster
      buffer lock in the buffer item unpin handler. The buffer lock is
      held by xfsaild attempting to flush an inode. The buffer happens to
      be pinned and so xfs_iflush() triggers an async log force to begin
      work required to get it unpinned. The log force is blocked waiting
      on the commit completion, which never occurs and thus leaves the
      filesystem deadlocked.
      
      The root problem is that aborted log I/O completion pots commit
      completion behind callback completion, which is unexpected for async
      log forces. Under normal running conditions, an async log force
      returns to the caller once the CIL ctx has been formatted/submitted
      and the commit completion event triggered at the tail end of
      xlog_cil_push(). If the filesystem has shutdown, however, we rely on
      xlog_cil_committed() to trigger the completion event and it happens
      to do so after running log item unpin callbacks. This makes it
      unsafe to invoke an async log force from contexts that hold locks
      that might also be required in log completion processing.
      
      To address this problem, wake commit completion waiters before
      aborting log items in the log I/O completion handler. This ensures
      that an async log force will not deadlock on held locks if the
      filesystem happens to shutdown. Note that it is still unsafe to
      issue a sync log force while holding such locks because a sync log
      force explicitly waits on the force completion, which occurs after
      log I/O completion processing.
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      545aa41f
    • Brian Foster's avatar
      xfs: fix use after free in buf log item unlock assert · 4d09807f
      Brian Foster authored
      The xfs_buf_log_item ->iop_unlock() callback asserts that the buffer
      is unlocked when either non-stale or aborted. This assert occurs
      after the bli refcount has been dropped and the log item potentially
      freed. The aborted check is thus a potential use after free. This
      problem has been reproduced with KASAN enabled via generic/475.
      
      Fix up xfs_buf_item_unlock() to query aborted state before the bli
      reference is dropped to prevent a potential use after free.
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      4d09807f
  3. 14 Apr, 2019 6 commits
    • Linus Torvalds's avatar
      Linux 5.1-rc5 · dc4060a5
      Linus Torvalds authored
      dc4060a5
    • Linus Torvalds's avatar
      Merge branch 'page-refs' (page ref overflow) · 6b3a7077
      Linus Torvalds authored
      Merge page ref overflow branch.
      
      Jann Horn reported that he can overflow the page ref count with
      sufficient memory (and a filesystem that is intentionally extremely
      slow).
      
      Admittedly it's not exactly easy.  To have more than four billion
      references to a page requires a minimum of 32GB of kernel memory just
      for the pointers to the pages, much less any metadata to keep track of
      those pointers.  Jann needed a total of 140GB of memory and a specially
      crafted filesystem that leaves all reads pending (in order to not ever
      free the page references and just keep adding more).
      
      Still, we have a fairly straightforward way to limit the two obvious
      user-controllable sources of page references: direct-IO like page
      references gotten through get_user_pages(), and the splice pipe page
      duplication.  So let's just do that.
      
      * branch page-refs:
        fs: prevent page refcount overflow in pipe_buf_get
        mm: prevent get_user_pages() from overflowing page refcount
        mm: add 'try_get_page()' helper function
        mm: make page ref count overflow check tighter and more explicit
      6b3a7077
    • Matthew Wilcox's avatar
      fs: prevent page refcount overflow in pipe_buf_get · 15fab63e
      Matthew Wilcox authored
      Change pipe_buf_get() to return a bool indicating whether it succeeded
      in raising the refcount of the page (if the thing in the pipe is a page).
      This removes another mechanism for overflowing the page refcount.  All
      callers converted to handle a failure.
      Reported-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarMatthew Wilcox <willy@infradead.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      15fab63e
    • Linus Torvalds's avatar
      mm: prevent get_user_pages() from overflowing page refcount · 8fde12ca
      Linus Torvalds authored
      If the page refcount wraps around past zero, it will be freed while
      there are still four billion references to it.  One of the possible
      avenues for an attacker to try to make this happen is by doing direct IO
      on a page multiple times.  This patch makes get_user_pages() refuse to
      take a new page reference if there are already more than two billion
      references to the page.
      Reported-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarMatthew Wilcox <willy@infradead.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8fde12ca
    • Linus Torvalds's avatar
      mm: add 'try_get_page()' helper function · 88b1a17d
      Linus Torvalds authored
      This is the same as the traditional 'get_page()' function, but instead
      of unconditionally incrementing the reference count of the page, it only
      does so if the count was "safe".  It returns whether the reference count
      was incremented (and is marked __must_check, since the caller obviously
      has to be aware of it).
      
      Also like 'get_page()', you can't use this function unless you already
      had a reference to the page.  The intent is that you can use this
      exactly like get_page(), but in situations where you want to limit the
      maximum reference count.
      
      The code currently does an unconditional WARN_ON_ONCE() if we ever hit
      the reference count issues (either zero or negative), as a notification
      that the conditional non-increment actually happened.
      
      NOTE! The count access for the "safety" check is inherently racy, but
      that doesn't matter since the buffer we use is basically half the range
      of the reference count (ie we look at the sign of the count).
      Acked-by: default avatarMatthew Wilcox <willy@infradead.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      88b1a17d
    • Linus Torvalds's avatar
      mm: make page ref count overflow check tighter and more explicit · f958d7b5
      Linus Torvalds authored
      We have a VM_BUG_ON() to check that the page reference count doesn't
      underflow (or get close to overflow) by checking the sign of the count.
      
      That's all fine, but we actually want to allow people to use a "get page
      ref unless it's already very high" helper function, and we want that one
      to use the sign of the page ref (without triggering this VM_BUG_ON).
      
      Change the VM_BUG_ON to only check for small underflows (or _very_ close
      to overflowing), and ignore overflows which have strayed into negative
      territory.
      Acked-by: default avatarMatthew Wilcox <willy@infradead.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f958d7b5
  4. 13 Apr, 2019 14 commits
  5. 12 Apr, 2019 5 commits