2018-06-06 10:42:14 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2016-08-03 09:12:25 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 Oracle. All Rights Reserved.
|
|
|
|
* Author: Darrick J. Wong <darrick.wong@oracle.com>
|
|
|
|
*/
|
|
|
|
#include "xfs.h"
|
|
|
|
#include "xfs_fs.h"
|
|
|
|
#include "xfs_shared.h"
|
|
|
|
#include "xfs_format.h"
|
|
|
|
#include "xfs_log_format.h"
|
|
|
|
#include "xfs_trans_resv.h"
|
|
|
|
#include "xfs_mount.h"
|
|
|
|
#include "xfs_defer.h"
|
|
|
|
#include "xfs_trans.h"
|
2018-08-01 22:20:32 +08:00
|
|
|
#include "xfs_buf_item.h"
|
2018-08-01 22:20:32 +08:00
|
|
|
#include "xfs_inode.h"
|
|
|
|
#include "xfs_inode_item.h"
|
2016-08-03 09:12:25 +08:00
|
|
|
#include "xfs_trace.h"
|
2020-09-26 08:39:51 +08:00
|
|
|
#include "xfs_icache.h"
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-28 07:18:13 +08:00
|
|
|
#include "xfs_log.h"
|
2021-10-13 05:11:01 +08:00
|
|
|
#include "xfs_rmap.h"
|
|
|
|
#include "xfs_refcount.h"
|
|
|
|
#include "xfs_bmap.h"
|
2021-10-13 05:17:01 +08:00
|
|
|
#include "xfs_alloc.h"
|
2022-05-04 10:39:02 +08:00
|
|
|
#include "xfs_buf.h"
|
xfs: separate out initial attr_set states
We current use XFS_DAS_UNINIT for several steps in the attr_set
state machine. We use it for setting shortform xattrs, converting
from shortform to leaf, leaf add, leaf-to-node and leaf add. All of
these things are essentially known before we start the state machine
iterating, so we really should separate them out:
XFS_DAS_SF_ADD:
- tries to do a shortform add
- on success -> done
- on ENOSPC converts to leaf, -> XFS_DAS_LEAF_ADD
- on error, dies.
XFS_DAS_LEAF_ADD:
- tries to do leaf add
- on success:
- inline attr -> done
- remote xattr || REPLACE -> XFS_DAS_FOUND_LBLK
- on ENOSPC converts to node, -> XFS_DAS_NODE_ADD
- on error, dies
XFS_DAS_NODE_ADD:
- tries to do node add
- on success:
- inline attr -> done
- remote xattr || REPLACE -> XFS_DAS_FOUND_NBLK
- on error, dies
This makes it easier to understand how the state machine starts
up and sets us up on the path to further state machine
simplifications.
This also converts the DAS state tracepoints to use strings rather
than numbers, as converting between enums and numbers requires
manual counting rather than just reading the name.
This also introduces a XFS_DAS_DONE state so that we can trace
successful operation completions easily.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-12 13:12:52 +08:00
|
|
|
#include "xfs_da_format.h"
|
|
|
|
#include "xfs_da_btree.h"
|
2022-05-04 10:41:02 +08:00
|
|
|
#include "xfs_attr.h"
|
2021-10-13 05:11:01 +08:00
|
|
|
|
|
|
|
static struct kmem_cache *xfs_defer_pending_cache;
|
2016-08-03 09:12:25 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Deferred Operations in XFS
|
|
|
|
*
|
|
|
|
* Due to the way locking rules work in XFS, certain transactions (block
|
|
|
|
* mapping and unmapping, typically) have permanent reservations so that
|
|
|
|
* we can roll the transaction to adhere to AG locking order rules and
|
|
|
|
* to unlock buffers between metadata updates. Prior to rmap/reflink,
|
|
|
|
* the mapping code had a mechanism to perform these deferrals for
|
|
|
|
* extents that were going to be freed; this code makes that facility
|
|
|
|
* more generic.
|
|
|
|
*
|
|
|
|
* When adding the reverse mapping and reflink features, it became
|
|
|
|
* necessary to perform complex remapping multi-transactions to comply
|
|
|
|
* with AG locking order rules, and to be able to spread a single
|
|
|
|
* refcount update operation (an operation on an n-block extent can
|
|
|
|
* update as many as n records!) among multiple transactions. XFS can
|
|
|
|
* roll a transaction to facilitate this, but using this facility
|
|
|
|
* requires us to log "intent" items in case log recovery needs to
|
|
|
|
* redo the operation, and to log "done" items to indicate that redo
|
|
|
|
* is not necessary.
|
|
|
|
*
|
|
|
|
* Deferred work is tracked in xfs_defer_pending items. Each pending
|
|
|
|
* item tracks one type of deferred work. Incoming work items (which
|
|
|
|
* have not yet had an intent logged) are attached to a pending item
|
|
|
|
* on the dop_intake list, where they wait for the caller to finish
|
|
|
|
* the deferred operations.
|
|
|
|
*
|
|
|
|
* Finishing a set of deferred operations is an involved process. To
|
|
|
|
* start, we define "rolling a deferred-op transaction" as follows:
|
|
|
|
*
|
|
|
|
* > For each xfs_defer_pending item on the dop_intake list,
|
|
|
|
* - Sort the work items in AG order. XFS locking
|
|
|
|
* order rules require us to lock buffers in AG order.
|
|
|
|
* - Create a log intent item for that type.
|
|
|
|
* - Attach it to the pending item.
|
|
|
|
* - Move the pending item from the dop_intake list to the
|
|
|
|
* dop_pending list.
|
|
|
|
* > Roll the transaction.
|
|
|
|
*
|
|
|
|
* NOTE: To avoid exceeding the transaction reservation, we limit the
|
|
|
|
* number of items that we attach to a given xfs_defer_pending.
|
|
|
|
*
|
|
|
|
* The actual finishing process looks like this:
|
|
|
|
*
|
|
|
|
* > For each xfs_defer_pending in the dop_pending list,
|
|
|
|
* - Roll the deferred-op transaction as above.
|
|
|
|
* - Create a log done item for that type, and attach it to the
|
|
|
|
* log intent item.
|
|
|
|
* - For each work item attached to the log intent item,
|
|
|
|
* * Perform the described action.
|
|
|
|
* * Attach the work item to the log done item.
|
2016-09-19 08:26:25 +08:00
|
|
|
* * If the result of doing the work was -EAGAIN, ->finish work
|
|
|
|
* wants a new transaction. See the "Requesting a Fresh
|
|
|
|
* Transaction while Finishing Deferred Work" section below for
|
|
|
|
* details.
|
2016-08-03 09:12:25 +08:00
|
|
|
*
|
|
|
|
* The key here is that we must log an intent item for all pending
|
|
|
|
* work items every time we roll the transaction, and that we must log
|
|
|
|
* a done item as soon as the work is completed. With this mechanism
|
|
|
|
* we can perform complex remapping operations, chaining intent items
|
|
|
|
* as needed.
|
|
|
|
*
|
2016-09-19 08:26:25 +08:00
|
|
|
* Requesting a Fresh Transaction while Finishing Deferred Work
|
|
|
|
*
|
|
|
|
* If ->finish_item decides that it needs a fresh transaction to
|
|
|
|
* finish the work, it must ask its caller (xfs_defer_finish) for a
|
|
|
|
* continuation. The most likely cause of this circumstance are the
|
|
|
|
* refcount adjust functions deciding that they've logged enough items
|
|
|
|
* to be at risk of exceeding the transaction reservation.
|
|
|
|
*
|
|
|
|
* To get a fresh transaction, we want to log the existing log done
|
|
|
|
* item to prevent the log intent item from replaying, immediately log
|
|
|
|
* a new log intent item with the unfinished work items, roll the
|
|
|
|
* transaction, and re-call ->finish_item wherever it left off. The
|
|
|
|
* log done item and the new log intent item must be in the same
|
|
|
|
* transaction or atomicity cannot be guaranteed; defer_finish ensures
|
|
|
|
* that this happens.
|
|
|
|
*
|
|
|
|
* This requires some coordination between ->finish_item and
|
|
|
|
* defer_finish. Upon deciding to request a new transaction,
|
|
|
|
* ->finish_item should update the current work item to reflect the
|
|
|
|
* unfinished work. Next, it should reset the log done item's list
|
|
|
|
* count to the number of items finished, and return -EAGAIN.
|
|
|
|
* defer_finish sees the -EAGAIN, logs the new log intent item
|
|
|
|
* with the remaining work items, and leaves the xfs_defer_pending
|
|
|
|
* item at the head of the dop_work queue. Then it rolls the
|
|
|
|
* transaction and picks up processing where it left off. It is
|
|
|
|
* required that ->finish_item must be careful to leave enough
|
|
|
|
* transaction reservation to fit the new log intent item.
|
|
|
|
*
|
2016-08-03 09:12:25 +08:00
|
|
|
* This is an example of remapping the extent (E, E+B) into file X at
|
|
|
|
* offset A and dealing with the extent (C, C+B) already being mapped
|
|
|
|
* there:
|
|
|
|
* +-------------------------------------------------+
|
|
|
|
* | Unmap file X startblock C offset A length B | t0
|
|
|
|
* | Intent to reduce refcount for extent (C, B) |
|
|
|
|
* | Intent to remove rmap (X, C, A, B) |
|
|
|
|
* | Intent to free extent (D, 1) (bmbt block) |
|
|
|
|
* | Intent to map (X, A, B) at startblock E |
|
|
|
|
* +-------------------------------------------------+
|
|
|
|
* | Map file X startblock E offset A length B | t1
|
|
|
|
* | Done mapping (X, E, A, B) |
|
|
|
|
* | Intent to increase refcount for extent (E, B) |
|
|
|
|
* | Intent to add rmap (X, E, A, B) |
|
|
|
|
* +-------------------------------------------------+
|
|
|
|
* | Reduce refcount for extent (C, B) | t2
|
2016-09-19 08:26:25 +08:00
|
|
|
* | Done reducing refcount for extent (C, 9) |
|
|
|
|
* | Intent to reduce refcount for extent (C+9, B-9) |
|
|
|
|
* | (ran out of space after 9 refcount updates) |
|
|
|
|
* +-------------------------------------------------+
|
|
|
|
* | Reduce refcount for extent (C+9, B+9) | t3
|
|
|
|
* | Done reducing refcount for extent (C+9, B-9) |
|
2016-08-03 09:12:25 +08:00
|
|
|
* | Increase refcount for extent (E, B) |
|
|
|
|
* | Done increasing refcount for extent (E, B) |
|
|
|
|
* | Intent to free extent (C, B) |
|
|
|
|
* | Intent to free extent (F, 1) (refcountbt block) |
|
|
|
|
* | Intent to remove rmap (F, 1, REFC) |
|
|
|
|
* +-------------------------------------------------+
|
2016-09-19 08:26:25 +08:00
|
|
|
* | Remove rmap (X, C, A, B) | t4
|
2016-08-03 09:12:25 +08:00
|
|
|
* | Done removing rmap (X, C, A, B) |
|
|
|
|
* | Add rmap (X, E, A, B) |
|
|
|
|
* | Done adding rmap (X, E, A, B) |
|
|
|
|
* | Remove rmap (F, 1, REFC) |
|
|
|
|
* | Done removing rmap (F, 1, REFC) |
|
|
|
|
* +-------------------------------------------------+
|
2016-09-19 08:26:25 +08:00
|
|
|
* | Free extent (C, B) | t5
|
2016-08-03 09:12:25 +08:00
|
|
|
* | Done freeing extent (C, B) |
|
|
|
|
* | Free extent (D, 1) |
|
|
|
|
* | Done freeing extent (D, 1) |
|
|
|
|
* | Free extent (F, 1) |
|
|
|
|
* | Done freeing extent (F, 1) |
|
|
|
|
* +-------------------------------------------------+
|
|
|
|
*
|
|
|
|
* If we should crash before t2 commits, log recovery replays
|
|
|
|
* the following intent items:
|
|
|
|
*
|
|
|
|
* - Intent to reduce refcount for extent (C, B)
|
|
|
|
* - Intent to remove rmap (X, C, A, B)
|
|
|
|
* - Intent to free extent (D, 1) (bmbt block)
|
|
|
|
* - Intent to increase refcount for extent (E, B)
|
|
|
|
* - Intent to add rmap (X, E, A, B)
|
|
|
|
*
|
|
|
|
* In the process of recovering, it should also generate and take care
|
|
|
|
* of these intent items:
|
|
|
|
*
|
|
|
|
* - Intent to free extent (C, B)
|
|
|
|
* - Intent to free extent (F, 1) (refcountbt block)
|
|
|
|
* - Intent to remove rmap (F, 1, REFC)
|
2016-09-19 08:26:25 +08:00
|
|
|
*
|
|
|
|
* Note that the continuation requested between t2 and t3 is likely to
|
|
|
|
* reoccur.
|
2016-08-03 09:12:25 +08:00
|
|
|
*/
|
|
|
|
|
2018-12-13 00:46:22 +08:00
|
|
|
static const struct xfs_defer_op_type *defer_op_types[] = {
|
|
|
|
[XFS_DEFER_OPS_TYPE_BMAP] = &xfs_bmap_update_defer_type,
|
|
|
|
[XFS_DEFER_OPS_TYPE_REFCOUNT] = &xfs_refcount_update_defer_type,
|
|
|
|
[XFS_DEFER_OPS_TYPE_RMAP] = &xfs_rmap_update_defer_type,
|
|
|
|
[XFS_DEFER_OPS_TYPE_FREE] = &xfs_extent_free_defer_type,
|
|
|
|
[XFS_DEFER_OPS_TYPE_AGFL_FREE] = &xfs_agfl_free_defer_type,
|
2022-05-09 17:09:07 +08:00
|
|
|
[XFS_DEFER_OPS_TYPE_ATTR] = &xfs_attr_defer_type,
|
2018-12-13 00:46:22 +08:00
|
|
|
};
|
2016-08-03 09:12:25 +08:00
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
/*
|
|
|
|
* Ensure there's a log intent item associated with this deferred work item if
|
|
|
|
* the operation must be restarted on crash. Returns 1 if there's a log item;
|
|
|
|
* 0 if there isn't; or a negative errno.
|
|
|
|
*/
|
|
|
|
static int
|
2020-05-01 03:52:20 +08:00
|
|
|
xfs_defer_create_intent(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_defer_pending *dfp,
|
|
|
|
bool sort)
|
|
|
|
{
|
|
|
|
const struct xfs_defer_op_type *ops = defer_op_types[dfp->dfp_type];
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
struct xfs_log_item *lip;
|
2020-05-01 03:52:20 +08:00
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
if (dfp->dfp_intent)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
lip = ops->create_intent(tp, &dfp->dfp_work, dfp->dfp_count, sort);
|
|
|
|
if (!lip)
|
|
|
|
return 0;
|
|
|
|
if (IS_ERR(lip))
|
|
|
|
return PTR_ERR(lip);
|
|
|
|
|
|
|
|
dfp->dfp_intent = lip;
|
|
|
|
return 1;
|
2020-05-01 03:52:20 +08:00
|
|
|
}
|
|
|
|
|
2016-08-03 09:12:25 +08:00
|
|
|
/*
|
|
|
|
* For each pending item in the intake list, log its intent item and the
|
|
|
|
* associated extents, then add the entire intake list to the end of
|
|
|
|
* the pending list.
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
*
|
|
|
|
* Returns 1 if at least one log item was associated with the deferred work;
|
|
|
|
* 0 if there are no log items; or a negative errno.
|
2016-08-03 09:12:25 +08:00
|
|
|
*/
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
static int
|
2018-08-01 22:20:34 +08:00
|
|
|
xfs_defer_create_intents(
|
2018-08-01 22:20:33 +08:00
|
|
|
struct xfs_trans *tp)
|
2016-08-03 09:12:25 +08:00
|
|
|
{
|
|
|
|
struct xfs_defer_pending *dfp;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
int ret = 0;
|
2016-08-03 09:12:25 +08:00
|
|
|
|
2018-08-01 22:20:35 +08:00
|
|
|
list_for_each_entry(dfp, &tp->t_dfops, dfp_list) {
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
int ret2;
|
|
|
|
|
2018-08-01 22:20:34 +08:00
|
|
|
trace_xfs_defer_create_intent(tp->t_mountp, dfp);
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
ret2 = xfs_defer_create_intent(tp, dfp, true);
|
|
|
|
if (ret2 < 0)
|
|
|
|
return ret2;
|
|
|
|
ret |= ret2;
|
2016-08-03 09:12:25 +08:00
|
|
|
}
|
2022-05-04 09:46:00 +08:00
|
|
|
return ret;
|
2016-08-03 09:12:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Abort all the intents that were committed. */
|
|
|
|
STATIC void
|
|
|
|
xfs_defer_trans_abort(
|
|
|
|
struct xfs_trans *tp,
|
2018-08-01 22:20:34 +08:00
|
|
|
struct list_head *dop_pending)
|
2016-08-03 09:12:25 +08:00
|
|
|
{
|
|
|
|
struct xfs_defer_pending *dfp;
|
2018-12-13 00:46:22 +08:00
|
|
|
const struct xfs_defer_op_type *ops;
|
2016-08-03 09:12:25 +08:00
|
|
|
|
2018-08-01 22:20:35 +08:00
|
|
|
trace_xfs_defer_trans_abort(tp, _RET_IP_);
|
2016-08-03 09:12:25 +08:00
|
|
|
|
2016-10-24 11:21:18 +08:00
|
|
|
/* Abort intent items that don't have a done item. */
|
2018-08-01 22:20:34 +08:00
|
|
|
list_for_each_entry(dfp, dop_pending, dfp_list) {
|
2018-12-13 00:46:22 +08:00
|
|
|
ops = defer_op_types[dfp->dfp_type];
|
2016-08-03 09:13:02 +08:00
|
|
|
trace_xfs_defer_pending_abort(tp->t_mountp, dfp);
|
2016-10-24 11:21:18 +08:00
|
|
|
if (dfp->dfp_intent && !dfp->dfp_done) {
|
2018-12-13 00:46:22 +08:00
|
|
|
ops->abort_intent(dfp->dfp_intent);
|
2016-10-24 11:21:18 +08:00
|
|
|
dfp->dfp_intent = NULL;
|
|
|
|
}
|
2016-08-03 09:12:25 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-09-17 08:28:06 +08:00
|
|
|
/*
|
|
|
|
* Capture resources that the caller said not to release ("held") when the
|
|
|
|
* transaction commits. Caller is responsible for zero-initializing @dres.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
xfs_defer_save_resources(
|
|
|
|
struct xfs_defer_resources *dres,
|
|
|
|
struct xfs_trans *tp)
|
2016-08-03 09:12:25 +08:00
|
|
|
{
|
2018-08-01 22:20:32 +08:00
|
|
|
struct xfs_buf_log_item *bli;
|
2018-08-01 22:20:32 +08:00
|
|
|
struct xfs_inode_log_item *ili;
|
2018-08-01 22:20:32 +08:00
|
|
|
struct xfs_log_item *lip;
|
2016-08-03 09:12:25 +08:00
|
|
|
|
2021-09-17 08:28:06 +08:00
|
|
|
BUILD_BUG_ON(NBBY * sizeof(dres->dr_ordered) < XFS_DEFER_OPS_NR_BUFS);
|
xfs: use ordered buffers to initialize dquot buffers during quotacheck
While QAing the new xfs_repair quotacheck code, I uncovered a quota
corruption bug resulting from a bad interaction between dquot buffer
initialization and quotacheck. The bug can be reproduced with the
following sequence:
# mkfs.xfs -f /dev/sdf
# mount /dev/sdf /opt -o usrquota
# su nobody -s /bin/bash -c 'touch /opt/barf'
# sync
# xfs_quota -x -c 'report -ahi' /opt
User quota on /opt (/dev/sdf)
Inodes
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 3 0 0 00 [------]
nobody 1 0 0 00 [------]
# xfs_io -x -c 'shutdown' /opt
# umount /opt
# mount /dev/sdf /opt -o usrquota
# touch /opt/man2
# xfs_quota -x -c 'report -ahi' /opt
User quota on /opt (/dev/sdf)
Inodes
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 1 0 0 00 [------]
nobody 1 0 0 00 [------]
# umount /opt
Notice how the initial quotacheck set the root dquot icount to 3
(rootino, rbmino, rsumino), but after shutdown -> remount -> recovery,
xfs_quota reports that the root dquot has only 1 icount. We haven't
deleted anything from the filesystem, which means that quota is now
under-counting. This behavior is not limited to icount or the root
dquot, but this is the shortest reproducer.
I traced the cause of this discrepancy to the way that we handle ondisk
dquot updates during quotacheck vs. regular fs activity. Normally, when
we allocate a disk block for a dquot, we log the buffer as a regular
(dquot) buffer. Subsequent updates to the dquots backed by that block
are done via separate dquot log item updates, which means that they
depend on the logged buffer update being written to disk before the
dquot items. Because individual dquots have their own LSN fields, that
initial dquot buffer must always be recovered.
However, the story changes for quotacheck, which can cause dquot block
allocations but persists the final dquot counter values via a delwri
list. Because recovery doesn't gate dquot buffer replay on an LSN, this
means that the initial dquot buffer can be replayed over the (newer)
contents that were delwritten at the end of quotacheck. In effect, this
re-initializes the dquot counters after they've been updated. If the
log does not contain any other dquot items to recover, the obsolete
dquot contents will not be corrected by log recovery.
Because quotacheck uses a transaction to log the setting of the CHKD
flags in the superblock, we skip quotacheck during the second mount
call, which allows the incorrect icount to remain.
Fix this by changing the ondisk dquot initialization function to use
ordered buffers to write out fresh dquot blocks if it detects that we're
running quotacheck. If the system goes down before quotacheck can
complete, the CHKD flags will not be set in the superblock and the next
mount will run quotacheck again, which can fix uninitialized dquot
buffers. This requires amending the defer code to maintaine ordered
buffer state across defer rolls for the sake of the dquot allocation
code.
For regular operations we preserve the current behavior since the dquot
items require properly initialized ondisk dquot records.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-05-14 06:33:27 +08:00
|
|
|
|
2018-08-01 22:20:34 +08:00
|
|
|
list_for_each_entry(lip, &tp->t_items, li_trans) {
|
2018-08-01 22:20:32 +08:00
|
|
|
switch (lip->li_type) {
|
|
|
|
case XFS_LI_BUF:
|
|
|
|
bli = container_of(lip, struct xfs_buf_log_item,
|
|
|
|
bli_item);
|
|
|
|
if (bli->bli_flags & XFS_BLI_HOLD) {
|
2021-09-17 08:28:06 +08:00
|
|
|
if (dres->dr_bufs >= XFS_DEFER_OPS_NR_BUFS) {
|
2018-08-01 22:20:32 +08:00
|
|
|
ASSERT(0);
|
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
xfs: use ordered buffers to initialize dquot buffers during quotacheck
While QAing the new xfs_repair quotacheck code, I uncovered a quota
corruption bug resulting from a bad interaction between dquot buffer
initialization and quotacheck. The bug can be reproduced with the
following sequence:
# mkfs.xfs -f /dev/sdf
# mount /dev/sdf /opt -o usrquota
# su nobody -s /bin/bash -c 'touch /opt/barf'
# sync
# xfs_quota -x -c 'report -ahi' /opt
User quota on /opt (/dev/sdf)
Inodes
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 3 0 0 00 [------]
nobody 1 0 0 00 [------]
# xfs_io -x -c 'shutdown' /opt
# umount /opt
# mount /dev/sdf /opt -o usrquota
# touch /opt/man2
# xfs_quota -x -c 'report -ahi' /opt
User quota on /opt (/dev/sdf)
Inodes
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 1 0 0 00 [------]
nobody 1 0 0 00 [------]
# umount /opt
Notice how the initial quotacheck set the root dquot icount to 3
(rootino, rbmino, rsumino), but after shutdown -> remount -> recovery,
xfs_quota reports that the root dquot has only 1 icount. We haven't
deleted anything from the filesystem, which means that quota is now
under-counting. This behavior is not limited to icount or the root
dquot, but this is the shortest reproducer.
I traced the cause of this discrepancy to the way that we handle ondisk
dquot updates during quotacheck vs. regular fs activity. Normally, when
we allocate a disk block for a dquot, we log the buffer as a regular
(dquot) buffer. Subsequent updates to the dquots backed by that block
are done via separate dquot log item updates, which means that they
depend on the logged buffer update being written to disk before the
dquot items. Because individual dquots have their own LSN fields, that
initial dquot buffer must always be recovered.
However, the story changes for quotacheck, which can cause dquot block
allocations but persists the final dquot counter values via a delwri
list. Because recovery doesn't gate dquot buffer replay on an LSN, this
means that the initial dquot buffer can be replayed over the (newer)
contents that were delwritten at the end of quotacheck. In effect, this
re-initializes the dquot counters after they've been updated. If the
log does not contain any other dquot items to recover, the obsolete
dquot contents will not be corrected by log recovery.
Because quotacheck uses a transaction to log the setting of the CHKD
flags in the superblock, we skip quotacheck during the second mount
call, which allows the incorrect icount to remain.
Fix this by changing the ondisk dquot initialization function to use
ordered buffers to write out fresh dquot blocks if it detects that we're
running quotacheck. If the system goes down before quotacheck can
complete, the CHKD flags will not be set in the superblock and the next
mount will run quotacheck again, which can fix uninitialized dquot
buffers. This requires amending the defer code to maintaine ordered
buffer state across defer rolls for the sake of the dquot allocation
code.
For regular operations we preserve the current behavior since the dquot
items require properly initialized ondisk dquot records.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-05-14 06:33:27 +08:00
|
|
|
if (bli->bli_flags & XFS_BLI_ORDERED)
|
2021-09-17 08:28:06 +08:00
|
|
|
dres->dr_ordered |=
|
|
|
|
(1U << dres->dr_bufs);
|
xfs: use ordered buffers to initialize dquot buffers during quotacheck
While QAing the new xfs_repair quotacheck code, I uncovered a quota
corruption bug resulting from a bad interaction between dquot buffer
initialization and quotacheck. The bug can be reproduced with the
following sequence:
# mkfs.xfs -f /dev/sdf
# mount /dev/sdf /opt -o usrquota
# su nobody -s /bin/bash -c 'touch /opt/barf'
# sync
# xfs_quota -x -c 'report -ahi' /opt
User quota on /opt (/dev/sdf)
Inodes
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 3 0 0 00 [------]
nobody 1 0 0 00 [------]
# xfs_io -x -c 'shutdown' /opt
# umount /opt
# mount /dev/sdf /opt -o usrquota
# touch /opt/man2
# xfs_quota -x -c 'report -ahi' /opt
User quota on /opt (/dev/sdf)
Inodes
User ID Used Soft Hard Warn/Grace
---------- ---------------------------------
root 1 0 0 00 [------]
nobody 1 0 0 00 [------]
# umount /opt
Notice how the initial quotacheck set the root dquot icount to 3
(rootino, rbmino, rsumino), but after shutdown -> remount -> recovery,
xfs_quota reports that the root dquot has only 1 icount. We haven't
deleted anything from the filesystem, which means that quota is now
under-counting. This behavior is not limited to icount or the root
dquot, but this is the shortest reproducer.
I traced the cause of this discrepancy to the way that we handle ondisk
dquot updates during quotacheck vs. regular fs activity. Normally, when
we allocate a disk block for a dquot, we log the buffer as a regular
(dquot) buffer. Subsequent updates to the dquots backed by that block
are done via separate dquot log item updates, which means that they
depend on the logged buffer update being written to disk before the
dquot items. Because individual dquots have their own LSN fields, that
initial dquot buffer must always be recovered.
However, the story changes for quotacheck, which can cause dquot block
allocations but persists the final dquot counter values via a delwri
list. Because recovery doesn't gate dquot buffer replay on an LSN, this
means that the initial dquot buffer can be replayed over the (newer)
contents that were delwritten at the end of quotacheck. In effect, this
re-initializes the dquot counters after they've been updated. If the
log does not contain any other dquot items to recover, the obsolete
dquot contents will not be corrected by log recovery.
Because quotacheck uses a transaction to log the setting of the CHKD
flags in the superblock, we skip quotacheck during the second mount
call, which allows the incorrect icount to remain.
Fix this by changing the ondisk dquot initialization function to use
ordered buffers to write out fresh dquot blocks if it detects that we're
running quotacheck. If the system goes down before quotacheck can
complete, the CHKD flags will not be set in the superblock and the next
mount will run quotacheck again, which can fix uninitialized dquot
buffers. This requires amending the defer code to maintaine ordered
buffer state across defer rolls for the sake of the dquot allocation
code.
For regular operations we preserve the current behavior since the dquot
items require properly initialized ondisk dquot records.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-05-14 06:33:27 +08:00
|
|
|
else
|
|
|
|
xfs_trans_dirty_buf(tp, bli->bli_buf);
|
2021-09-17 08:28:06 +08:00
|
|
|
dres->dr_bp[dres->dr_bufs++] = bli->bli_buf;
|
2018-08-01 22:20:32 +08:00
|
|
|
}
|
|
|
|
break;
|
2018-08-01 22:20:32 +08:00
|
|
|
case XFS_LI_INODE:
|
|
|
|
ili = container_of(lip, struct xfs_inode_log_item,
|
|
|
|
ili_item);
|
|
|
|
if (ili->ili_lock_flags == 0) {
|
2021-09-17 08:28:06 +08:00
|
|
|
if (dres->dr_inos >= XFS_DEFER_OPS_NR_INODES) {
|
2018-08-01 22:20:32 +08:00
|
|
|
ASSERT(0);
|
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
2018-08-01 22:20:34 +08:00
|
|
|
xfs_trans_log_inode(tp, ili->ili_inode,
|
2018-08-01 22:20:32 +08:00
|
|
|
XFS_ILOG_CORE);
|
2021-09-17 08:28:06 +08:00
|
|
|
dres->dr_ip[dres->dr_inos++] = ili->ili_inode;
|
2018-08-01 22:20:32 +08:00
|
|
|
}
|
|
|
|
break;
|
2018-08-01 22:20:32 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2017-12-08 11:07:02 +08:00
|
|
|
|
2021-09-17 08:28:06 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Attach the held resources to the transaction. */
|
|
|
|
static void
|
|
|
|
xfs_defer_restore_resources(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_defer_resources *dres)
|
|
|
|
{
|
|
|
|
unsigned short i;
|
|
|
|
|
|
|
|
/* Rejoin the joined inodes. */
|
|
|
|
for (i = 0; i < dres->dr_inos; i++)
|
|
|
|
xfs_trans_ijoin(tp, dres->dr_ip[i], 0);
|
|
|
|
|
|
|
|
/* Rejoin the buffers and dirty them so the log moves forward. */
|
|
|
|
for (i = 0; i < dres->dr_bufs; i++) {
|
|
|
|
xfs_trans_bjoin(tp, dres->dr_bp[i]);
|
|
|
|
if (dres->dr_ordered & (1U << i))
|
|
|
|
xfs_trans_ordered_buf(tp, dres->dr_bp[i]);
|
|
|
|
xfs_trans_bhold(tp, dres->dr_bp[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Roll a transaction so we can do some deferred op processing. */
|
|
|
|
STATIC int
|
|
|
|
xfs_defer_trans_roll(
|
|
|
|
struct xfs_trans **tpp)
|
|
|
|
{
|
|
|
|
struct xfs_defer_resources dres = { };
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = xfs_defer_save_resources(&dres, *tpp);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
|
|
|
|
trace_xfs_defer_trans_roll(*tpp, _RET_IP_);
|
2016-08-03 09:13:02 +08:00
|
|
|
|
2019-04-25 00:27:41 +08:00
|
|
|
/*
|
|
|
|
* Roll the transaction. Rolling always given a new transaction (even
|
|
|
|
* if committing the old one fails!) to hand back to the caller, so we
|
|
|
|
* join the held resources to the new transaction so that we always
|
|
|
|
* return with the held resources joined to @tpp, no matter what
|
|
|
|
* happened.
|
|
|
|
*/
|
2018-08-01 22:20:34 +08:00
|
|
|
error = xfs_trans_roll(tpp);
|
2016-08-03 09:12:25 +08:00
|
|
|
|
2021-09-17 08:28:06 +08:00
|
|
|
xfs_defer_restore_resources(*tpp, &dres);
|
2017-12-08 11:07:02 +08:00
|
|
|
|
2019-04-25 00:27:41 +08:00
|
|
|
if (error)
|
2021-09-17 08:28:06 +08:00
|
|
|
trace_xfs_defer_trans_roll_error(*tpp, error);
|
2016-08-03 09:12:25 +08:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2018-08-01 22:20:34 +08:00
|
|
|
/*
|
|
|
|
* Free up any items left in the list.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
xfs_defer_cancel_list(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct list_head *dop_list)
|
|
|
|
{
|
|
|
|
struct xfs_defer_pending *dfp;
|
|
|
|
struct xfs_defer_pending *pli;
|
|
|
|
struct list_head *pwi;
|
|
|
|
struct list_head *n;
|
2018-12-13 00:46:22 +08:00
|
|
|
const struct xfs_defer_op_type *ops;
|
2018-08-01 22:20:34 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Free the pending items. Caller should already have arranged
|
|
|
|
* for the intent items to be released.
|
|
|
|
*/
|
|
|
|
list_for_each_entry_safe(dfp, pli, dop_list, dfp_list) {
|
2018-12-13 00:46:22 +08:00
|
|
|
ops = defer_op_types[dfp->dfp_type];
|
2018-08-01 22:20:34 +08:00
|
|
|
trace_xfs_defer_cancel_list(mp, dfp);
|
|
|
|
list_del(&dfp->dfp_list);
|
|
|
|
list_for_each_safe(pwi, n, &dfp->dfp_work) {
|
|
|
|
list_del(pwi);
|
|
|
|
dfp->dfp_count--;
|
2018-12-13 00:46:22 +08:00
|
|
|
ops->cancel_item(pwi);
|
2018-08-01 22:20:34 +08:00
|
|
|
}
|
|
|
|
ASSERT(dfp->dfp_count == 0);
|
2021-10-13 05:11:01 +08:00
|
|
|
kmem_cache_free(xfs_defer_pending_cache, dfp);
|
2018-08-01 22:20:34 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-28 07:18:13 +08:00
|
|
|
/*
|
|
|
|
* Prevent a log intent item from pinning the tail of the log by logging a
|
|
|
|
* done item to release the intent item; and then log a new intent item.
|
|
|
|
* The caller should provide a fresh transaction and roll it after we're done.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
xfs_defer_relog(
|
|
|
|
struct xfs_trans **tpp,
|
|
|
|
struct list_head *dfops)
|
|
|
|
{
|
2020-09-26 08:39:58 +08:00
|
|
|
struct xlog *log = (*tpp)->t_mountp->m_log;
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-28 07:18:13 +08:00
|
|
|
struct xfs_defer_pending *dfp;
|
2020-09-26 08:39:58 +08:00
|
|
|
xfs_lsn_t threshold_lsn = NULLCOMMITLSN;
|
|
|
|
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-28 07:18:13 +08:00
|
|
|
|
|
|
|
ASSERT((*tpp)->t_flags & XFS_TRANS_PERM_LOG_RES);
|
|
|
|
|
|
|
|
list_for_each_entry(dfp, dfops, dfp_list) {
|
|
|
|
/*
|
|
|
|
* If the log intent item for this deferred op is not a part of
|
|
|
|
* the current log checkpoint, relog the intent item to keep
|
|
|
|
* the log tail moving forward. We're ok with this being racy
|
|
|
|
* because an incorrect decision means we'll be a little slower
|
|
|
|
* at pushing the tail.
|
|
|
|
*/
|
|
|
|
if (dfp->dfp_intent == NULL ||
|
|
|
|
xfs_log_item_in_current_chkpt(dfp->dfp_intent))
|
|
|
|
continue;
|
|
|
|
|
2020-09-26 08:39:58 +08:00
|
|
|
/*
|
|
|
|
* Figure out where we need the tail to be in order to maintain
|
|
|
|
* the minimum required free space in the log. Only sample
|
|
|
|
* the log threshold once per call.
|
|
|
|
*/
|
|
|
|
if (threshold_lsn == NULLCOMMITLSN) {
|
|
|
|
threshold_lsn = xlog_grant_push_threshold(log, 0);
|
|
|
|
if (threshold_lsn == NULLCOMMITLSN)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (XFS_LSN_CMP(dfp->dfp_intent->li_lsn, threshold_lsn) >= 0)
|
|
|
|
continue;
|
|
|
|
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-28 07:18:13 +08:00
|
|
|
trace_xfs_defer_relog_intent((*tpp)->t_mountp, dfp);
|
|
|
|
XFS_STATS_INC((*tpp)->t_mountp, defer_relog);
|
|
|
|
dfp->dfp_intent = xfs_trans_item_relog(dfp->dfp_intent, *tpp);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((*tpp)->t_flags & XFS_TRANS_DIRTY)
|
|
|
|
return xfs_defer_trans_roll(tpp);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-01 03:52:21 +08:00
|
|
|
/*
|
|
|
|
* Log an intent-done item for the first pending intent, and finish the work
|
|
|
|
* items.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
xfs_defer_finish_one(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_defer_pending *dfp)
|
|
|
|
{
|
|
|
|
const struct xfs_defer_op_type *ops = defer_op_types[dfp->dfp_type];
|
2020-05-01 03:52:22 +08:00
|
|
|
struct xfs_btree_cur *state = NULL;
|
2020-05-01 03:52:21 +08:00
|
|
|
struct list_head *li, *n;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
trace_xfs_defer_pending_finish(tp->t_mountp, dfp);
|
|
|
|
|
|
|
|
dfp->dfp_done = ops->create_done(tp, dfp->dfp_intent, dfp->dfp_count);
|
|
|
|
list_for_each_safe(li, n, &dfp->dfp_work) {
|
|
|
|
list_del(li);
|
|
|
|
dfp->dfp_count--;
|
2020-05-01 03:52:22 +08:00
|
|
|
error = ops->finish_item(tp, dfp->dfp_done, li, &state);
|
2020-05-01 03:52:21 +08:00
|
|
|
if (error == -EAGAIN) {
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
int ret;
|
|
|
|
|
2020-05-01 03:52:21 +08:00
|
|
|
/*
|
|
|
|
* Caller wants a fresh transaction; put the work item
|
|
|
|
* back on the list and log a new log intent item to
|
|
|
|
* replace the old one. See "Requesting a Fresh
|
|
|
|
* Transaction while Finishing Deferred Work" above.
|
|
|
|
*/
|
|
|
|
list_add(li, &dfp->dfp_work);
|
|
|
|
dfp->dfp_count++;
|
|
|
|
dfp->dfp_done = NULL;
|
2020-09-22 00:15:09 +08:00
|
|
|
dfp->dfp_intent = NULL;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
ret = xfs_defer_create_intent(tp, dfp, false);
|
|
|
|
if (ret < 0)
|
|
|
|
error = ret;
|
2020-05-01 03:52:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Done with the dfp, free it. */
|
|
|
|
list_del(&dfp->dfp_list);
|
2021-10-13 05:11:01 +08:00
|
|
|
kmem_cache_free(xfs_defer_pending_cache, dfp);
|
2020-05-01 03:52:21 +08:00
|
|
|
out:
|
|
|
|
if (ops->finish_cleanup)
|
|
|
|
ops->finish_cleanup(tp, state, error);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2016-08-03 09:12:25 +08:00
|
|
|
/*
|
|
|
|
* Finish all the pending work. This involves logging intent items for
|
|
|
|
* any work items that wandered in since the last transaction roll (if
|
|
|
|
* one has even happened), rolling the transaction, and finishing the
|
|
|
|
* work items in the first item on the logged-and-pending list.
|
|
|
|
*
|
|
|
|
* If an inode is provided, relog it to the new transaction.
|
|
|
|
*/
|
|
|
|
int
|
2018-07-25 04:43:15 +08:00
|
|
|
xfs_defer_finish_noroll(
|
2018-07-25 04:43:15 +08:00
|
|
|
struct xfs_trans **tp)
|
2016-08-03 09:12:25 +08:00
|
|
|
{
|
2022-05-04 09:46:00 +08:00
|
|
|
struct xfs_defer_pending *dfp = NULL;
|
2016-08-03 09:12:25 +08:00
|
|
|
int error = 0;
|
2018-08-01 22:20:34 +08:00
|
|
|
LIST_HEAD(dop_pending);
|
2016-08-03 09:12:25 +08:00
|
|
|
|
|
|
|
ASSERT((*tp)->t_flags & XFS_TRANS_PERM_LOG_RES);
|
|
|
|
|
2018-08-01 22:20:35 +08:00
|
|
|
trace_xfs_defer_finish(*tp, _RET_IP_);
|
2016-08-03 09:13:02 +08:00
|
|
|
|
2016-08-03 09:12:25 +08:00
|
|
|
/* Until we run out of pending work to finish... */
|
2018-08-01 22:20:35 +08:00
|
|
|
while (!list_empty(&dop_pending) || !list_empty(&(*tp)->t_dfops)) {
|
xfs: change the order in which child and parent defer ops are finished
The defer ops code has been finishing items in the wrong order -- if a
top level defer op creates items A and B, and finishing item A creates
more defer ops A1 and A2, we'll put the new items on the end of the
chain and process them in the order A B A1 A2. This is kind of weird,
since it's convenient for programmers to be able to think of A and B as
an ordered sequence where all the sub-tasks for A must finish before we
move on to B, e.g. A A1 A2 D.
Right now, our log intent items are not so complex that this matters,
but this will become important for the atomic extent swapping patchset.
In order to maintain correct reference counting of extents, we have to
unmap and remap extents in that order, and we want to complete that work
before moving on to the next range that the user wants to swap. This
patch fixes defer ops to satsify that requirement.
The primary symptom of the incorrect order was noticed in an early
performance analysis of the atomic extent swap code. An astonishingly
large number of deferred work items accumulated when userspace requested
an atomic update of two very fragmented files. The cause of this was
traced to the same ordering bug in the inner loop of
xfs_defer_finish_noroll.
If the ->finish_item method of a deferred operation queues new deferred
operations, those new deferred ops are appended to the tail of the
pending work list. To illustrate, say that a caller creates a
transaction t0 with four deferred operations D0-D3. The first thing
defer ops does is roll the transaction to t1, leaving us with:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
Let's say that finishing each of D0-D3 will create two new deferred ops.
After finish D0 and roll, we'll have the following chain:
t2: D1(t0), D2(t0), D3(t0), d4(t1), d5(t1)
d4 and d5 were logged to t1. Notice that while we're about to start
work on D1, we haven't actually completed all the work implied by D0
being finished. So far we've been careful (or lucky) to structure the
dfops callers such that D1 doesn't depend on d4 or d5 being finished,
but this is a potential logic bomb.
There's a second problem lurking. Let's see what happens as we finish
D1-D3:
t3: D2(t0), D3(t0), d4(t1), d5(t1), d6(t2), d7(t2)
t4: D3(t0), d4(t1), d5(t1), d6(t2), d7(t2), d8(t3), d9(t3)
t5: d4(t1), d5(t1), d6(t2), d7(t2), d8(t3), d9(t3), d10(t4), d11(t4)
Let's say that d4-d11 are simple work items that don't queue any other
operations, which means that we can complete each d4 and roll to t6:
t6: d5(t1), d6(t2), d7(t2), d8(t3), d9(t3), d10(t4), d11(t4)
t7: d6(t2), d7(t2), d8(t3), d9(t3), d10(t4), d11(t4)
...
t11: d10(t4), d11(t4)
t12: d11(t4)
<done>
When we try to roll to transaction #12, we're holding defer op d11,
which we logged way back in t4. This means that the tail of the log is
pinned at t4. If the log is very small or there are a lot of other
threads updating metadata, this means that we might have wrapped the log
and cannot get roll to t11 because there isn't enough space left before
we'd run into t4.
Let's shift back to the original failure. I mentioned before that I
discovered this flaw while developing the atomic file update code. In
that scenario, we have a defer op (D0) that finds a range of file blocks
to remap, creates a handful of new defer ops to do that, and then asks
to be continued with however much work remains.
So, D0 is the original swapext deferred op. The first thing defer ops
does is rolls to t1:
t1: D0(t0)
We try to finish D0, logging d1 and d2 in the process, but can't get all
the work done. We log a done item and a new intent item for the work
that D0 still has to do, and roll to t2:
t2: D0'(t1), d1(t1), d2(t1)
We roll and try to finish D0', but still can't get all the work done, so
we log a done item and a new intent item for it, requeue D0 a second
time, and roll to t3:
t3: D0''(t2), d1(t1), d2(t1), d3(t2), d4(t2)
If it takes 48 more rolls to complete D0, then we'll finally dispense
with D0 in t50:
t50: D<fifty primes>(t49), d1(t1), ..., d102(t50)
We then try to roll again to get a chain like this:
t51: d1(t1), d2(t1), ..., d101(t50), d102(t50)
...
t152: d102(t50)
<done>
Notice that in rolling to transaction #51, we're holding on to a log
intent item for d1 that was logged in transaction #1. This means that
the tail of the log is pinned at t1. If the log is very small or there
are a lot of other threads updating metadata, this means that we might
have wrapped the log and cannot roll to t51 because there isn't enough
space left before we'd run into t1. This is of course problem #2 again.
But notice the third problem with this scenario: we have 102 defer ops
tied to this transaction! Each of these items are backed by pinned
kernel memory, which means that we risk OOM if the chains get too long.
Yikes. Problem #1 is a subtle logic bomb that could hit someone in the
future; problem #2 applies (rarely) to the current upstream, and problem
#3 applies to work under development.
This is not how incremental deferred operations were supposed to work.
The dfops design of logging in the same transaction an intent-done item
and a new intent item for the work remaining was to make it so that we
only have to juggle enough deferred work items to finish that one small
piece of work. Deferred log item recovery will find that first
unfinished work item and restart it, no matter how many other intent
items might follow it in the log. Therefore, it's ok to put the new
intents at the start of the dfops chain.
For the first example, the chains look like this:
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
For the second example, the chains look like this:
t1: D0(t0)
t2: d1(t1), d2(t1), D0'(t1)
t3: d2(t1), D0'(t1)
t4: D0'(t1)
t5: d1(t4), d2(t4), D0''(t4)
...
t148: D0<50 primes>(t147)
t149: d101(t148), d102(t148)
t150: d102(t148)
<done>
This actually sucks more for pinning the log tail (we try to roll to t10
while holding an intent item that was logged in t1) but we've solved
problem #1. We've also reduced the maximum chain length from:
sum(all the new items) + nr_original_items
to:
max(new items that each original item creates) + nr_original_items
This solves problem #3 by sharply reducing the number of defer ops that
can be attached to a transaction at any given time. The change makes
the problem of log tail pinning worse, but is improvement we need to
solve problem #2. Actually solving #2, however, is left to the next
patch.
Note that a subsequent analysis of some hard-to-trigger reflink and COW
livelocks on extremely fragmented filesystems (or systems running a lot
of IO threads) showed the same symptoms -- uncomfortably large numbers
of incore deferred work items and occasional stalls in the transaction
grant code while waiting for log reservations. I think this patch and
the next one will also solve these problems.
As originally written, the code used list_splice_tail_init instead of
list_splice_init, so change that, and leave a short comment explaining
our actions.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-26 08:39:51 +08:00
|
|
|
/*
|
|
|
|
* Deferred items that are created in the process of finishing
|
|
|
|
* other deferred work items should be queued at the head of
|
|
|
|
* the pending list, which puts them ahead of the deferred work
|
|
|
|
* that was created by the caller. This keeps the number of
|
|
|
|
* pending work items to a minimum, which decreases the amount
|
|
|
|
* of time that any one intent item can stick around in memory,
|
|
|
|
* pinning the log tail.
|
|
|
|
*/
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
int has_intents = xfs_defer_create_intents(*tp);
|
2022-05-04 09:46:00 +08:00
|
|
|
|
xfs: change the order in which child and parent defer ops are finished
The defer ops code has been finishing items in the wrong order -- if a
top level defer op creates items A and B, and finishing item A creates
more defer ops A1 and A2, we'll put the new items on the end of the
chain and process them in the order A B A1 A2. This is kind of weird,
since it's convenient for programmers to be able to think of A and B as
an ordered sequence where all the sub-tasks for A must finish before we
move on to B, e.g. A A1 A2 D.
Right now, our log intent items are not so complex that this matters,
but this will become important for the atomic extent swapping patchset.
In order to maintain correct reference counting of extents, we have to
unmap and remap extents in that order, and we want to complete that work
before moving on to the next range that the user wants to swap. This
patch fixes defer ops to satsify that requirement.
The primary symptom of the incorrect order was noticed in an early
performance analysis of the atomic extent swap code. An astonishingly
large number of deferred work items accumulated when userspace requested
an atomic update of two very fragmented files. The cause of this was
traced to the same ordering bug in the inner loop of
xfs_defer_finish_noroll.
If the ->finish_item method of a deferred operation queues new deferred
operations, those new deferred ops are appended to the tail of the
pending work list. To illustrate, say that a caller creates a
transaction t0 with four deferred operations D0-D3. The first thing
defer ops does is roll the transaction to t1, leaving us with:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
Let's say that finishing each of D0-D3 will create two new deferred ops.
After finish D0 and roll, we'll have the following chain:
t2: D1(t0), D2(t0), D3(t0), d4(t1), d5(t1)
d4 and d5 were logged to t1. Notice that while we're about to start
work on D1, we haven't actually completed all the work implied by D0
being finished. So far we've been careful (or lucky) to structure the
dfops callers such that D1 doesn't depend on d4 or d5 being finished,
but this is a potential logic bomb.
There's a second problem lurking. Let's see what happens as we finish
D1-D3:
t3: D2(t0), D3(t0), d4(t1), d5(t1), d6(t2), d7(t2)
t4: D3(t0), d4(t1), d5(t1), d6(t2), d7(t2), d8(t3), d9(t3)
t5: d4(t1), d5(t1), d6(t2), d7(t2), d8(t3), d9(t3), d10(t4), d11(t4)
Let's say that d4-d11 are simple work items that don't queue any other
operations, which means that we can complete each d4 and roll to t6:
t6: d5(t1), d6(t2), d7(t2), d8(t3), d9(t3), d10(t4), d11(t4)
t7: d6(t2), d7(t2), d8(t3), d9(t3), d10(t4), d11(t4)
...
t11: d10(t4), d11(t4)
t12: d11(t4)
<done>
When we try to roll to transaction #12, we're holding defer op d11,
which we logged way back in t4. This means that the tail of the log is
pinned at t4. If the log is very small or there are a lot of other
threads updating metadata, this means that we might have wrapped the log
and cannot get roll to t11 because there isn't enough space left before
we'd run into t4.
Let's shift back to the original failure. I mentioned before that I
discovered this flaw while developing the atomic file update code. In
that scenario, we have a defer op (D0) that finds a range of file blocks
to remap, creates a handful of new defer ops to do that, and then asks
to be continued with however much work remains.
So, D0 is the original swapext deferred op. The first thing defer ops
does is rolls to t1:
t1: D0(t0)
We try to finish D0, logging d1 and d2 in the process, but can't get all
the work done. We log a done item and a new intent item for the work
that D0 still has to do, and roll to t2:
t2: D0'(t1), d1(t1), d2(t1)
We roll and try to finish D0', but still can't get all the work done, so
we log a done item and a new intent item for it, requeue D0 a second
time, and roll to t3:
t3: D0''(t2), d1(t1), d2(t1), d3(t2), d4(t2)
If it takes 48 more rolls to complete D0, then we'll finally dispense
with D0 in t50:
t50: D<fifty primes>(t49), d1(t1), ..., d102(t50)
We then try to roll again to get a chain like this:
t51: d1(t1), d2(t1), ..., d101(t50), d102(t50)
...
t152: d102(t50)
<done>
Notice that in rolling to transaction #51, we're holding on to a log
intent item for d1 that was logged in transaction #1. This means that
the tail of the log is pinned at t1. If the log is very small or there
are a lot of other threads updating metadata, this means that we might
have wrapped the log and cannot roll to t51 because there isn't enough
space left before we'd run into t1. This is of course problem #2 again.
But notice the third problem with this scenario: we have 102 defer ops
tied to this transaction! Each of these items are backed by pinned
kernel memory, which means that we risk OOM if the chains get too long.
Yikes. Problem #1 is a subtle logic bomb that could hit someone in the
future; problem #2 applies (rarely) to the current upstream, and problem
#3 applies to work under development.
This is not how incremental deferred operations were supposed to work.
The dfops design of logging in the same transaction an intent-done item
and a new intent item for the work remaining was to make it so that we
only have to juggle enough deferred work items to finish that one small
piece of work. Deferred log item recovery will find that first
unfinished work item and restart it, no matter how many other intent
items might follow it in the log. Therefore, it's ok to put the new
intents at the start of the dfops chain.
For the first example, the chains look like this:
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
For the second example, the chains look like this:
t1: D0(t0)
t2: d1(t1), d2(t1), D0'(t1)
t3: d2(t1), D0'(t1)
t4: D0'(t1)
t5: d1(t4), d2(t4), D0''(t4)
...
t148: D0<50 primes>(t147)
t149: d101(t148), d102(t148)
t150: d102(t148)
<done>
This actually sucks more for pinning the log tail (we try to roll to t10
while holding an intent item that was logged in t1) but we've solved
problem #1. We've also reduced the maximum chain length from:
sum(all the new items) + nr_original_items
to:
max(new items that each original item creates) + nr_original_items
This solves problem #3 by sharply reducing the number of defer ops that
can be attached to a transaction at any given time. The change makes
the problem of log tail pinning worse, but is improvement we need to
solve problem #2. Actually solving #2, however, is left to the next
patch.
Note that a subsequent analysis of some hard-to-trigger reflink and COW
livelocks on extremely fragmented filesystems (or systems running a lot
of IO threads) showed the same symptoms -- uncomfortably large numbers
of incore deferred work items and occasional stalls in the transaction
grant code while waiting for log reservations. I think this patch and
the next one will also solve these problems.
As originally written, the code used list_splice_tail_init instead of
list_splice_init, so change that, and leave a short comment explaining
our actions.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-26 08:39:51 +08:00
|
|
|
list_splice_init(&(*tp)->t_dfops, &dop_pending);
|
2016-08-03 09:12:25 +08:00
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
if (has_intents < 0) {
|
|
|
|
error = has_intents;
|
|
|
|
goto out_shutdown;
|
|
|
|
}
|
2022-05-04 09:46:00 +08:00
|
|
|
if (has_intents || dfp) {
|
|
|
|
error = xfs_defer_trans_roll(tp);
|
|
|
|
if (error)
|
|
|
|
goto out_shutdown;
|
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead
to pinning the log tail. Taking up the defer ops chain examples from
the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops
chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0)
t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
t3: d5(t1), D1(t0), D2(t0), D3(t0)
...
t9: d9(t7), D3(t0)
t10: D3(t0)
t11: d10(t10), d11(t10)
t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto
an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in
the defer ops processing chain to reduce the maximum chain length. Now
make xfs_defer_finish_noroll capable of relogging the entire chain
periodically so that we can always move the log tail forward. Most
chains will never get relogged, except for operations that generate very
long chains (large extents containing many blocks with different sharing
levels) or are on filesystems with small logs and a lot of ongoing
metadata updates.
Callers are now required to ensure that the transaction reservation is
large enough to handle logging done items and new intent items for the
maximum possible chain length. Most callers are careful to keep the
chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent
was logged in a previous checkpoint, since there's no point in relogging
an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
2020-09-28 07:18:13 +08:00
|
|
|
|
2022-05-04 09:46:00 +08:00
|
|
|
/* Relog intent items to keep the log moving. */
|
|
|
|
error = xfs_defer_relog(tp, &dop_pending);
|
|
|
|
if (error)
|
|
|
|
goto out_shutdown;
|
|
|
|
}
|
2016-08-03 09:12:25 +08:00
|
|
|
|
2018-08-01 22:20:34 +08:00
|
|
|
dfp = list_first_entry(&dop_pending, struct xfs_defer_pending,
|
|
|
|
dfp_list);
|
2020-05-01 03:52:21 +08:00
|
|
|
error = xfs_defer_finish_one(*tp, dfp);
|
|
|
|
if (error && error != -EAGAIN)
|
|
|
|
goto out_shutdown;
|
2018-08-01 22:20:33 +08:00
|
|
|
}
|
2018-07-25 04:43:10 +08:00
|
|
|
|
2018-08-01 22:20:35 +08:00
|
|
|
trace_xfs_defer_finish_done(*tp, _RET_IP_);
|
2018-08-01 22:20:33 +08:00
|
|
|
return 0;
|
2020-05-01 03:52:21 +08:00
|
|
|
|
|
|
|
out_shutdown:
|
|
|
|
xfs_defer_trans_abort(*tp, &dop_pending);
|
|
|
|
xfs_force_shutdown((*tp)->t_mountp, SHUTDOWN_CORRUPT_INCORE);
|
|
|
|
trace_xfs_defer_finish_error(*tp, error);
|
|
|
|
xfs_defer_cancel_list((*tp)->t_mountp, &dop_pending);
|
|
|
|
xfs_defer_cancel(*tp);
|
|
|
|
return error;
|
2016-08-03 09:12:25 +08:00
|
|
|
}
|
|
|
|
|
2018-07-25 04:43:15 +08:00
|
|
|
int
|
|
|
|
xfs_defer_finish(
|
|
|
|
struct xfs_trans **tp)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Finish and roll the transaction once more to avoid returning to the
|
|
|
|
* caller with a dirty transaction.
|
|
|
|
*/
|
|
|
|
error = xfs_defer_finish_noroll(tp);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
if ((*tp)->t_flags & XFS_TRANS_DIRTY) {
|
|
|
|
error = xfs_defer_trans_roll(tp);
|
2018-08-01 22:20:34 +08:00
|
|
|
if (error) {
|
|
|
|
xfs_force_shutdown((*tp)->t_mountp,
|
|
|
|
SHUTDOWN_CORRUPT_INCORE);
|
2018-07-25 04:43:15 +08:00
|
|
|
return error;
|
2018-08-01 22:20:34 +08:00
|
|
|
}
|
2018-07-25 04:43:15 +08:00
|
|
|
}
|
2020-09-26 08:39:27 +08:00
|
|
|
|
|
|
|
/* Reset LOWMODE now that we've finished all the dfops. */
|
|
|
|
ASSERT(list_empty(&(*tp)->t_dfops));
|
|
|
|
(*tp)->t_flags &= ~XFS_TRANS_LOWMODE;
|
2018-07-25 04:43:15 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-08-03 09:12:25 +08:00
|
|
|
void
|
2018-08-01 22:20:30 +08:00
|
|
|
xfs_defer_cancel(
|
2018-08-01 22:20:34 +08:00
|
|
|
struct xfs_trans *tp)
|
2016-08-03 09:12:25 +08:00
|
|
|
{
|
2018-08-01 22:20:34 +08:00
|
|
|
struct xfs_mount *mp = tp->t_mountp;
|
2016-08-03 09:12:25 +08:00
|
|
|
|
2018-08-01 22:20:35 +08:00
|
|
|
trace_xfs_defer_cancel(tp, _RET_IP_);
|
|
|
|
xfs_defer_cancel_list(mp, &tp->t_dfops);
|
2016-08-03 09:12:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Add an item for later deferred processing. */
|
|
|
|
void
|
|
|
|
xfs_defer_add(
|
2018-08-01 22:20:34 +08:00
|
|
|
struct xfs_trans *tp,
|
2016-08-03 09:12:25 +08:00
|
|
|
enum xfs_defer_ops_type type,
|
|
|
|
struct list_head *li)
|
|
|
|
{
|
|
|
|
struct xfs_defer_pending *dfp = NULL;
|
2018-12-13 00:46:22 +08:00
|
|
|
const struct xfs_defer_op_type *ops;
|
2016-08-03 09:12:25 +08:00
|
|
|
|
2018-08-01 22:20:34 +08:00
|
|
|
ASSERT(tp->t_flags & XFS_TRANS_PERM_LOG_RES);
|
2018-12-13 00:46:22 +08:00
|
|
|
BUILD_BUG_ON(ARRAY_SIZE(defer_op_types) != XFS_DEFER_OPS_TYPE_MAX);
|
2018-08-01 22:20:34 +08:00
|
|
|
|
2016-08-03 09:12:25 +08:00
|
|
|
/*
|
|
|
|
* Add the item to a pending item at the end of the intake list.
|
|
|
|
* If the last pending item has the same type, reuse it. Else,
|
|
|
|
* create a new pending item at the end of the intake list.
|
|
|
|
*/
|
2018-08-01 22:20:35 +08:00
|
|
|
if (!list_empty(&tp->t_dfops)) {
|
|
|
|
dfp = list_last_entry(&tp->t_dfops,
|
2016-08-03 09:12:25 +08:00
|
|
|
struct xfs_defer_pending, dfp_list);
|
2018-12-13 00:46:22 +08:00
|
|
|
ops = defer_op_types[dfp->dfp_type];
|
|
|
|
if (dfp->dfp_type != type ||
|
|
|
|
(ops->max_items && dfp->dfp_count >= ops->max_items))
|
2016-08-03 09:12:25 +08:00
|
|
|
dfp = NULL;
|
|
|
|
}
|
|
|
|
if (!dfp) {
|
2021-10-13 05:11:01 +08:00
|
|
|
dfp = kmem_cache_zalloc(xfs_defer_pending_cache,
|
|
|
|
GFP_NOFS | __GFP_NOFAIL);
|
2018-12-13 00:46:22 +08:00
|
|
|
dfp->dfp_type = type;
|
2016-08-03 09:12:25 +08:00
|
|
|
dfp->dfp_intent = NULL;
|
2016-08-30 11:51:39 +08:00
|
|
|
dfp->dfp_done = NULL;
|
2016-08-03 09:12:25 +08:00
|
|
|
dfp->dfp_count = 0;
|
|
|
|
INIT_LIST_HEAD(&dfp->dfp_work);
|
2018-08-01 22:20:35 +08:00
|
|
|
list_add_tail(&dfp->dfp_list, &tp->t_dfops);
|
2016-08-03 09:12:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
list_add_tail(li, &dfp->dfp_work);
|
|
|
|
dfp->dfp_count++;
|
|
|
|
}
|
|
|
|
|
2018-07-25 04:43:11 +08:00
|
|
|
/*
|
2018-08-01 22:20:35 +08:00
|
|
|
* Move deferred ops from one transaction to another and reset the source to
|
|
|
|
* initial state. This is primarily used to carry state forward across
|
|
|
|
* transaction rolls with pending dfops.
|
2018-07-25 04:43:11 +08:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_defer_move(
|
2018-08-01 22:20:30 +08:00
|
|
|
struct xfs_trans *dtp,
|
|
|
|
struct xfs_trans *stp)
|
2018-07-25 04:43:11 +08:00
|
|
|
{
|
2018-08-01 22:20:35 +08:00
|
|
|
list_splice_init(&stp->t_dfops, &dtp->t_dfops);
|
2018-07-25 04:43:11 +08:00
|
|
|
|
2018-08-01 22:20:31 +08:00
|
|
|
/*
|
|
|
|
* Low free space mode was historically controlled by a dfops field.
|
|
|
|
* This meant that low mode state potentially carried across multiple
|
|
|
|
* transaction rolls. Transfer low mode on a dfops move to preserve
|
|
|
|
* that behavior.
|
|
|
|
*/
|
|
|
|
dtp->t_flags |= (stp->t_flags & XFS_TRANS_LOWMODE);
|
2020-09-26 08:39:27 +08:00
|
|
|
stp->t_flags &= ~XFS_TRANS_LOWMODE;
|
2018-07-25 04:43:11 +08:00
|
|
|
}
|
2020-09-22 00:15:09 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepare a chain of fresh deferred ops work items to be completed later. Log
|
|
|
|
* recovery requires the ability to put off until later the actual finishing
|
|
|
|
* work so that it can process unfinished items recovered from the log in
|
|
|
|
* correct order.
|
|
|
|
*
|
|
|
|
* Create and log intent items for all the work that we're capturing so that we
|
|
|
|
* can be assured that the items will get replayed if the system goes down
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
* before log recovery gets a chance to finish the work it put off. The entire
|
|
|
|
* deferred ops state is transferred to the capture structure and the
|
|
|
|
* transaction is then ready for the caller to commit it. If there are no
|
|
|
|
* intent items to capture, this function returns NULL.
|
2020-09-26 08:39:51 +08:00
|
|
|
*
|
|
|
|
* If capture_ip is not NULL, the capture structure will obtain an extra
|
|
|
|
* reference to the inode.
|
2020-09-22 00:15:09 +08:00
|
|
|
*/
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
static struct xfs_defer_capture *
|
|
|
|
xfs_defer_ops_capture(
|
2021-09-17 08:28:07 +08:00
|
|
|
struct xfs_trans *tp)
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
{
|
|
|
|
struct xfs_defer_capture *dfc;
|
2021-09-17 08:28:07 +08:00
|
|
|
unsigned short i;
|
|
|
|
int error;
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
|
|
|
|
if (list_empty(&tp->t_dfops))
|
|
|
|
return NULL;
|
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
error = xfs_defer_create_intents(tp);
|
|
|
|
if (error < 0)
|
|
|
|
return ERR_PTR(error);
|
|
|
|
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
/* Create an object to capture the defer ops. */
|
|
|
|
dfc = kmem_zalloc(sizeof(*dfc), KM_NOFS);
|
|
|
|
INIT_LIST_HEAD(&dfc->dfc_list);
|
|
|
|
INIT_LIST_HEAD(&dfc->dfc_dfops);
|
|
|
|
|
|
|
|
/* Move the dfops chain and transaction state to the capture struct. */
|
|
|
|
list_splice_init(&tp->t_dfops, &dfc->dfc_dfops);
|
|
|
|
dfc->dfc_tpflags = tp->t_flags & XFS_TRANS_LOWMODE;
|
|
|
|
tp->t_flags &= ~XFS_TRANS_LOWMODE;
|
|
|
|
|
2020-09-26 08:39:49 +08:00
|
|
|
/* Capture the remaining block reservations along with the dfops. */
|
|
|
|
dfc->dfc_blkres = tp->t_blk_res - tp->t_blk_res_used;
|
|
|
|
dfc->dfc_rtxres = tp->t_rtx_res - tp->t_rtx_res_used;
|
|
|
|
|
2020-09-26 08:39:50 +08:00
|
|
|
/* Preserve the log reservation size. */
|
|
|
|
dfc->dfc_logres = tp->t_log_res;
|
|
|
|
|
2021-09-17 08:28:07 +08:00
|
|
|
error = xfs_defer_save_resources(&dfc->dfc_held, tp);
|
|
|
|
if (error) {
|
|
|
|
/*
|
|
|
|
* Resource capture should never fail, but if it does, we
|
|
|
|
* still have to shut down the log and release things
|
|
|
|
* properly.
|
|
|
|
*/
|
|
|
|
xfs_force_shutdown(tp->t_mountp, SHUTDOWN_CORRUPT_INCORE);
|
|
|
|
}
|
|
|
|
|
2020-09-26 08:39:51 +08:00
|
|
|
/*
|
2021-09-17 08:28:07 +08:00
|
|
|
* Grab extra references to the inodes and buffers because callers are
|
|
|
|
* expected to release their held references after we commit the
|
|
|
|
* transaction.
|
2020-09-26 08:39:51 +08:00
|
|
|
*/
|
2021-09-17 08:28:07 +08:00
|
|
|
for (i = 0; i < dfc->dfc_held.dr_inos; i++) {
|
|
|
|
ASSERT(xfs_isilocked(dfc->dfc_held.dr_ip[i], XFS_ILOCK_EXCL));
|
|
|
|
ihold(VFS_I(dfc->dfc_held.dr_ip[i]));
|
2020-09-26 08:39:51 +08:00
|
|
|
}
|
|
|
|
|
2021-09-17 08:28:07 +08:00
|
|
|
for (i = 0; i < dfc->dfc_held.dr_bufs; i++)
|
|
|
|
xfs_buf_hold(dfc->dfc_held.dr_bp[i]);
|
|
|
|
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
return dfc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Release all resources that we used to capture deferred ops. */
|
2020-09-22 00:15:09 +08:00
|
|
|
void
|
2021-09-17 08:28:07 +08:00
|
|
|
xfs_defer_ops_capture_free(
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct xfs_defer_capture *dfc)
|
|
|
|
{
|
2021-09-17 08:28:07 +08:00
|
|
|
unsigned short i;
|
|
|
|
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
xfs_defer_cancel_list(mp, &dfc->dfc_dfops);
|
2021-09-17 08:28:07 +08:00
|
|
|
|
|
|
|
for (i = 0; i < dfc->dfc_held.dr_bufs; i++)
|
|
|
|
xfs_buf_relse(dfc->dfc_held.dr_bp[i]);
|
|
|
|
|
|
|
|
for (i = 0; i < dfc->dfc_held.dr_inos; i++)
|
|
|
|
xfs_irele(dfc->dfc_held.dr_ip[i]);
|
|
|
|
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
kmem_free(dfc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Capture any deferred ops and commit the transaction. This is the last step
|
2020-09-26 08:39:51 +08:00
|
|
|
* needed to finish a log intent item that we recovered from the log. If any
|
|
|
|
* of the deferred ops operate on an inode, the caller must pass in that inode
|
|
|
|
* so that the reference can be transferred to the capture structure. The
|
|
|
|
* caller must hold ILOCK_EXCL on the inode, and must unlock it before calling
|
|
|
|
* xfs_defer_ops_continue.
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
*/
|
|
|
|
int
|
|
|
|
xfs_defer_ops_capture_and_commit(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct list_head *capture_list)
|
|
|
|
{
|
|
|
|
struct xfs_mount *mp = tp->t_mountp;
|
|
|
|
struct xfs_defer_capture *dfc;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
/* If we don't capture anything, commit transaction and exit. */
|
2021-09-17 08:28:07 +08:00
|
|
|
dfc = xfs_defer_ops_capture(tp);
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
if (IS_ERR(dfc)) {
|
|
|
|
xfs_trans_cancel(tp);
|
|
|
|
return PTR_ERR(dfc);
|
|
|
|
}
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
if (!dfc)
|
|
|
|
return xfs_trans_commit(tp);
|
|
|
|
|
|
|
|
/* Commit the transaction and add the capture structure to the list. */
|
|
|
|
error = xfs_trans_commit(tp);
|
|
|
|
if (error) {
|
2021-09-17 08:28:07 +08:00
|
|
|
xfs_defer_ops_capture_free(mp, dfc);
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_add_tail(&dfc->dfc_list, capture_list);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Attach a chain of captured deferred ops to a new transaction and free the
|
2020-09-26 08:39:51 +08:00
|
|
|
* capture structure. If an inode was captured, it will be passed back to the
|
|
|
|
* caller with ILOCK_EXCL held and joined to the transaction with lockflags==0.
|
|
|
|
* The caller now owns the inode reference.
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_defer_ops_continue(
|
|
|
|
struct xfs_defer_capture *dfc,
|
2020-09-26 08:39:51 +08:00
|
|
|
struct xfs_trans *tp,
|
2021-09-17 08:28:07 +08:00
|
|
|
struct xfs_defer_resources *dres)
|
2020-09-22 00:15:09 +08:00
|
|
|
{
|
2022-05-04 10:39:02 +08:00
|
|
|
unsigned int i;
|
|
|
|
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
ASSERT(tp->t_flags & XFS_TRANS_PERM_LOG_RES);
|
|
|
|
ASSERT(!(tp->t_flags & XFS_TRANS_DIRTY));
|
|
|
|
|
2022-05-04 10:39:02 +08:00
|
|
|
/* Lock the captured resources to the new transaction. */
|
2021-09-17 08:28:07 +08:00
|
|
|
if (dfc->dfc_held.dr_inos == 2)
|
|
|
|
xfs_lock_two_inodes(dfc->dfc_held.dr_ip[0], XFS_ILOCK_EXCL,
|
|
|
|
dfc->dfc_held.dr_ip[1], XFS_ILOCK_EXCL);
|
|
|
|
else if (dfc->dfc_held.dr_inos == 1)
|
|
|
|
xfs_ilock(dfc->dfc_held.dr_ip[0], XFS_ILOCK_EXCL);
|
2022-05-04 10:39:02 +08:00
|
|
|
|
|
|
|
for (i = 0; i < dfc->dfc_held.dr_bufs; i++)
|
|
|
|
xfs_buf_lock(dfc->dfc_held.dr_bp[i]);
|
|
|
|
|
|
|
|
/* Join the captured resources to the new transaction. */
|
2021-09-17 08:28:07 +08:00
|
|
|
xfs_defer_restore_resources(tp, &dfc->dfc_held);
|
|
|
|
memcpy(dres, &dfc->dfc_held, sizeof(struct xfs_defer_resources));
|
2022-05-04 10:39:02 +08:00
|
|
|
dres->dr_bufs = 0;
|
2020-09-26 08:39:51 +08:00
|
|
|
|
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the
log, it's possible that the replay will cause the creation of more
deferred work items. As outlined in commit 509955823cc9c ("xfs: log
recovery should replay deferred ops in order"), later work items have an
implicit ordering dependency on earlier work items. Therefore, recovery
must replay the items (both recovered and created) in the same order
that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction
to collect deferred ops that get created in the process of recovering a
log intent item to prevent them from being committed before the rest of
the recovered intent items. After we finish committing all the
recovered log items, we allocate a transaction with an enormous block
reservation, splice our huge list of created deferred ops into that
transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow
nested transactions; the splicing of the defer ops list is is inelegant
and has to be done twice per recovery function; and the broken way we
handle inode pointers and block reservations cause subtle use-after-free
and allocator problems that will be fixed by this patch and the two
patches after it.
Therefore, replace the hokey empty transaction with a structure designed
to capture each chain of deferred ops that are created as part of
recovering a single unfinished log intent. Finally, refactor the loop
that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2020-09-26 08:39:37 +08:00
|
|
|
/* Move captured dfops chain and state to the transaction. */
|
|
|
|
list_splice_init(&dfc->dfc_dfops, &tp->t_dfops);
|
|
|
|
tp->t_flags |= dfc->dfc_tpflags;
|
|
|
|
|
|
|
|
kmem_free(dfc);
|
2020-09-22 00:15:09 +08:00
|
|
|
}
|
2021-09-17 08:28:07 +08:00
|
|
|
|
|
|
|
/* Release the resources captured and continued during recovery. */
|
|
|
|
void
|
|
|
|
xfs_defer_resources_rele(
|
|
|
|
struct xfs_defer_resources *dres)
|
|
|
|
{
|
|
|
|
unsigned short i;
|
|
|
|
|
|
|
|
for (i = 0; i < dres->dr_inos; i++) {
|
|
|
|
xfs_iunlock(dres->dr_ip[i], XFS_ILOCK_EXCL);
|
|
|
|
xfs_irele(dres->dr_ip[i]);
|
|
|
|
dres->dr_ip[i] = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < dres->dr_bufs; i++) {
|
|
|
|
xfs_buf_relse(dres->dr_bp[i]);
|
|
|
|
dres->dr_bp[i] = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
dres->dr_inos = 0;
|
|
|
|
dres->dr_bufs = 0;
|
|
|
|
dres->dr_ordered = 0;
|
|
|
|
}
|
2021-10-13 05:11:01 +08:00
|
|
|
|
|
|
|
static inline int __init
|
|
|
|
xfs_defer_init_cache(void)
|
|
|
|
{
|
|
|
|
xfs_defer_pending_cache = kmem_cache_create("xfs_defer_pending",
|
|
|
|
sizeof(struct xfs_defer_pending),
|
|
|
|
0, 0, NULL);
|
|
|
|
|
|
|
|
return xfs_defer_pending_cache != NULL ? 0 : -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
xfs_defer_destroy_cache(void)
|
|
|
|
{
|
|
|
|
kmem_cache_destroy(xfs_defer_pending_cache);
|
|
|
|
xfs_defer_pending_cache = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set up caches for deferred work items. */
|
|
|
|
int __init
|
|
|
|
xfs_defer_init_item_caches(void)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = xfs_defer_init_cache();
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
error = xfs_rmap_intent_init_cache();
|
|
|
|
if (error)
|
|
|
|
goto err;
|
|
|
|
error = xfs_refcount_intent_init_cache();
|
|
|
|
if (error)
|
|
|
|
goto err;
|
|
|
|
error = xfs_bmap_intent_init_cache();
|
2021-10-13 05:17:01 +08:00
|
|
|
if (error)
|
|
|
|
goto err;
|
|
|
|
error = xfs_extfree_intent_init_cache();
|
2022-05-22 13:59:48 +08:00
|
|
|
if (error)
|
|
|
|
goto err;
|
|
|
|
error = xfs_attr_intent_init_cache();
|
2022-05-04 10:41:02 +08:00
|
|
|
if (error)
|
|
|
|
goto err;
|
2021-10-13 05:11:01 +08:00
|
|
|
return 0;
|
|
|
|
err:
|
|
|
|
xfs_defer_destroy_item_caches();
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Destroy all the deferred work item caches, if they've been allocated. */
|
|
|
|
void
|
|
|
|
xfs_defer_destroy_item_caches(void)
|
|
|
|
{
|
2022-05-22 13:59:48 +08:00
|
|
|
xfs_attr_intent_destroy_cache();
|
2021-10-13 05:17:01 +08:00
|
|
|
xfs_extfree_intent_destroy_cache();
|
2021-10-13 05:11:01 +08:00
|
|
|
xfs_bmap_intent_destroy_cache();
|
|
|
|
xfs_refcount_intent_destroy_cache();
|
|
|
|
xfs_rmap_intent_destroy_cache();
|
|
|
|
xfs_defer_destroy_cache();
|
|
|
|
}
|