1. 18 1月, 2018 6 次提交
  2. 17 1月, 2018 1 次提交
    • B
      xfs: cancel tx on xfs_defer_finish() error during xattr set/remove · c4685628
      Brian Foster 提交于
      Chris Dunlop reports a problem where an xattr operation fails,
      reports the following error to syslog and hangs during unmount:
      
       ================================================
       [ BUG: lock held when returning to user space! ]
       ...
       ------------------------------------------------
       <PID> is leaving the kernel with locks still held!
       1 lock held by <PID>:
        #0:  (sb_internal){......}, at: [<ffffffffa07692a3>] xfs_trans_alloc+0xe3/0x130 [xfs]
      
      The failure/shutdown occurs during deferred ops processing which
      leads to an error return from xfs_defer_finish() via
      xfs_attr_leaf_addname(). While the root cause of the failure is
      unknown corruption, the cause of the subsequent BUG above and
      unmount hang is failure to cancel the transaction before returning
      to userspace.
      
      The transaction is not cancelled because the out_defer_cancel error
      handling paths in the xfs_attr_[leaf|node]_[add|remove]name()
      functions clear args.trans without releasing the transaction. The
      callers therefore lose the reference to the transaction and fail to
      cancel it.
      
      Since xfs_attr_[set|remove]() always cancel args.trans when != NULL
      and xfs_defer_finish()->...->xfs_trans_roll() should always return
      with a valid transaction, update the leaf/node xattr functions to
      not reset args.trans in the error path responsible for cancelling
      deferred ops.
      Reported-by: NChris Dunlop <chris@onthe.net.au>
      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>
      c4685628
  3. 13 1月, 2018 4 次提交
  4. 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
  5. 09 1月, 2018 26 次提交
  6. 22 12月, 2017 2 次提交
    • D
      xfs: only skip rmap owner checks for unknown-owner rmap removal · 68c58e9b
      Darrick J. Wong 提交于
      For rmap removal, refactor the rmap owner checks into a separate
      function, then skip the checks if we are performing an unknown-owner
      removal.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      68c58e9b
    • D
      xfs: always honor OWN_UNKNOWN rmap removal requests · 33df3a9c
      Darrick J. Wong 提交于
      Calling xfs_rmap_free with an unknown owner is supposed to remove any
      rmaps covering that range regardless of owner.  This is used by the EFI
      recovery code to say "we're freeing this, it mustn't be owned by
      anything anymore", but for whatever reason xfs_free_ag_extent filters
      them out.
      
      Therefore, remove the filter and make xfs_rmap_unmap actually treat it
      as a wildcard owner -- free anything that's already there, and if
      there's no owner at all then that's fine too.
      
      There are two existing callers of bmap_add_free that take care the rmap
      deferred ops themselves and use OWN_UNKNOWN to skip the EFI-based rmap
      cleanup; convert these to use OWN_NULL (via helpers), and now we really
      require that an RUI (if any) gets added to the defer ops before any EFI.
      
      Lastly, now that xfs_free_extent filters out OWN_NULL rmap free requests,
      growfs will have to consult directly with the rmap to ensure that there
      aren't any rmaps in the grown region.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      33df3a9c