xfs: Fix double unlock in defer capture code
authorAllison Henderson <allison.henderson@oracle.com>
Wed, 4 May 2022 02:39:02 +0000 (12:39 +1000)
committerDave Chinner <david@fromorbit.com>
Wed, 4 May 2022 02:39:02 +0000 (12:39 +1000)
commit7b3ec2b20e44f579c022ad62243aa18c04c6addc
tree1fddf259d9fdcfa2fb4e1d5d4011362e34b6a41c
parent86810a9ebd9e69498524c57a83f1271ade56ded8
xfs: Fix double unlock in defer capture code

The new deferred attr patch set uncovered a double unlock in the
recent port of the defer ops capture and continue code.  During log
recovery, we're allowed to hold buffers to a transaction that's being
used to replay an intent item.  When we capture the resources as part
of scheduling a continuation of an intent chain, we call xfs_buf_hold
to retain our reference to the buffer beyond the transaction commit,
but we do /not/ call xfs_trans_bhold to maintain the buffer lock.
This means that xfs_defer_ops_continue needs to relock the buffers
before xfs_defer_restore_resources joins then tothe new transaction.

Additionally, the buffers should not be passed back via the dres
structure since they need to remain locked unlike the inodes.  So
simply set dr_bufs to zero after populating the dres structure.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Allison Henderson <allison.henderson@oracle.com>
Reviewed-by: Chandan Babu R <chandan.babu@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
fs/xfs/libxfs/xfs_defer.c