1. 29 1月, 2018 12 次提交
  2. 18 1月, 2018 25 次提交
  3. 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
  4. 13 1月, 2018 2 次提交
    • B
      xfs: account finobt blocks properly in perag reservation · ad90bb58
      Brian Foster 提交于
      XFS started using the perag metadata reservation pool for free inode
      btree blocks in commit 76d771b4 ("xfs: use per-AG reservations
      for the finobt"). To handle backwards compatibility, finobt blocks
      are accounted against the pool so long as the full reservation is
      available at mount time. Otherwise the ->m_inotbt_nores flag is set
      and the filesystem falls back to the traditional per-transaction
      finobt reservation.
      
      This commit has two problems:
      
      - finobt blocks are always accounted against the metadata
        reservation on allocation, regardless of ->m_inotbt_nores state
      - finobt blocks are never returned to the reservation pool on free
      
      The first problem affects reflink+finobt filesystems where the full
      finobt reservation is not available at mount time. finobt blocks are
      essentially stolen from the reflink reservation, putting refcountbt
      management at risk of allocation failure. The second problem is an
      unconditional leak of metadata reservation whenever finobt is
      enabled.
      
      Update the finobt block allocation callouts to consider
      ->m_inotbt_nores and account blocks appropriately. Blocks should be
      consistently accounted against the metadata pool when
      ->m_inotbt_nores is false and otherwise tagged as RESV_NONE.
      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>
      ad90bb58
    • C
      xfs: fix check on struct_version for versions 4 or greater · a8789a5a
      Colin Ian King 提交于
      It appears that the check for versions 4 or more is incorrect and is
      off-by-one. Fix this.
      
      Detected by CoverityScan, CID#1463775 ("Logically dead code")
      
      Fixes: ac503a4c ("xfs: refactor the geometry structure filling function")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      a8789a5a