1. 08 Jul, 2017 1 commit
    • Darrick J. Wong's avatar
      xfs: don't crash on unexpected holes in dir/attr btrees · cd87d867
      Darrick J. Wong authored
      In quite a few places we call xfs_da_read_buf with a mappedbno that we
      don't control, then assume that the function passes back either an error
      code or a buffer pointer.  Unfortunately, if mappedbno == -2 and bno
      maps to a hole, we get a return code of zero and a NULL buffer, which
      means that we crash if we actually try to use that buffer pointer.  This
      happens immediately when we set the buffer type for transaction context.
      
      Therefore, check that we have no error code and a non-NULL bp before
      trying to use bp.  This patch is a follow-up to an incomplete fix in
      96a3aefb ("xfs: don't crash if reading a directory results in an
      unexpected hole").
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      cd87d867
  2. 07 Jul, 2017 1 commit
    • Darrick J. Wong's avatar
      xfs: rename MAXPATHLEN to XFS_SYMLINK_MAXLEN · 6eb0b8df
      Darrick J. Wong authored
      XFS has a maximum symlink target length of 1024 bytes; this is a
      holdover from the Irix days.  Unfortunately, the constant establishing
      this is 'MAXPATHLEN' and is /not/ the same as the Linux MAXPATHLEN,
      which is 4096.
      
      The kernel enforces its 1024 byte MAXPATHLEN on symlink targets, but
      xfsprogs picks up the (Linux) system 4096 byte MAXPATHLEN, which means
      that xfs_repair doesn't complain about oversized symlinks.
      
      Since this is an on-disk format constraint, put the define in the XFS
      namespace and move everything over to use the new name.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      6eb0b8df
  3. 05 Jul, 2017 1 commit
    • Brian Foster's avatar
      xfs: fix contiguous dquot chunk iteration livelock · 2192b0ba
      Brian Foster authored
      The patch below updated xfs_dq_get_next_id() to use the XFS iext
      lookup helpers to locate the next quota id rather than to seek for
      data in the quota file. The updated code fails to correctly handle
      the case where the quota inode might have contiguous chunks part of
      the same extent. In this case, the start block offset is calculated
      based on the next expected id but the extent lookup returns the same
      start offset as for the previous chunk. This causes the returned id
      to go backwards and livelocks the quota iteration. This problem is
      reproduced intermittently by generic/232.
      
      To handle this case, check whether the startoff from the extent
      lookup is behind the startoff calculated from the next quota id. If
      so, bump up got.br_startoff to the specific file offset that is
      expected to hold the next dquot chunk.
      
      Fixes: bda250db ("xfs: rewrite xfs_dq_get_next_id using xfs_iext_lookup_extent")
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      2192b0ba
  4. 03 Jul, 2017 3 commits
  5. 02 Jul, 2017 3 commits
  6. 28 Jun, 2017 9 commits
  7. 24 Jun, 2017 1 commit
    • Brian Foster's avatar
      xfs: free uncommitted transactions during log recovery · 39775431
      Brian Foster authored
      Log recovery allocates in-core transaction and member item data
      structures on-demand as it processes the on-disk log. Transactions
      are allocated on first encounter on-disk and stored in a hash table
      structure where they are easily accessible for subsequent lookups.
      Transaction items are also allocated on demand and are attached to
      the associated transactions.
      
      When a commit record is encountered in the log, the transaction is
      committed to the fs and the in-core structures are freed. If a
      filesystem crashes or shuts down before all in-core log buffers are
      flushed to the log, however, not all transactions may have commit
      records in the log. As expected, the modifications in such an
      incomplete transaction are not replayed to the fs. The in-core data
      structures for the partial transaction are never freed, however,
      resulting in a memory leak.
      
      Update xlog_do_recovery_pass() to first correctly initialize the
      hash table array so empty lists can be distinguished from populated
      lists on function exit. Update xlog_recover_free_trans() to always
      remove the transaction from the list prior to freeing the associated
      memory. Finally, walk the hash table of transaction lists as the
      last step before it goes out of scope and free any transactions that
      may remain on the lists. This prevents a memory leak of partial
      transactions in the log.
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      39775431
  8. 20 Jun, 2017 7 commits
  9. 19 Jun, 2017 14 commits