2018-06-06 02:42:14 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2005-11-02 03:58:39 +00:00
|
|
|
* Copyright (c) 2000-2001,2005 Silicon Graphics, Inc.
|
|
|
|
* All Rights Reserved.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
#include "xfs.h"
|
2005-11-02 03:38:42 +00:00
|
|
|
#include "xfs_fs.h"
|
2014-11-28 03:25:04 +00:00
|
|
|
#include "xfs_format.h"
|
2013-10-22 23:50:10 +00:00
|
|
|
#include "xfs_log_format.h"
|
|
|
|
#include "xfs_trans_resv.h"
|
2016-08-03 01:23:49 +00:00
|
|
|
#include "xfs_bit.h"
|
2019-06-29 02:25:35 +00:00
|
|
|
#include "xfs_shared.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "xfs_mount.h"
|
2019-06-29 02:28:17 +00:00
|
|
|
#include "xfs_defer.h"
|
2013-10-22 23:50:10 +00:00
|
|
|
#include "xfs_trans.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "xfs_trans_priv.h"
|
|
|
|
#include "xfs_extfree_item.h"
|
2013-12-13 00:00:43 +00:00
|
|
|
#include "xfs_log.h"
|
2016-08-03 01:33:42 +00:00
|
|
|
#include "xfs_btree.h"
|
|
|
|
#include "xfs_rmap.h"
|
2019-06-29 02:28:17 +00:00
|
|
|
#include "xfs_alloc.h"
|
|
|
|
#include "xfs_bmap.h"
|
|
|
|
#include "xfs_trace.h"
|
2019-11-02 16:40:53 +00:00
|
|
|
#include "xfs_error.h"
|
2020-05-01 23:00:48 +00:00
|
|
|
#include "xfs_log_priv.h"
|
2020-05-01 23:00:45 +00:00
|
|
|
#include "xfs_log_recover.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
kmem_zone_t *xfs_efi_zone;
|
|
|
|
kmem_zone_t *xfs_efd_zone;
|
|
|
|
|
2020-05-01 23:00:50 +00:00
|
|
|
static const struct xfs_item_ops xfs_efi_item_ops;
|
|
|
|
|
2010-06-23 08:11:15 +00:00
|
|
|
static inline struct xfs_efi_log_item *EFI_ITEM(struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return container_of(lip, struct xfs_efi_log_item, efi_item);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-05-01 23:00:48 +00:00
|
|
|
STATIC void
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efi_item_free(
|
|
|
|
struct xfs_efi_log_item *efip)
|
2005-06-21 05:41:19 +00:00
|
|
|
{
|
xfs: allocate log vector buffers outside CIL context lock
One of the problems we currently have with delayed logging is that
under serious memory pressure we can deadlock memory reclaim. THis
occurs when memory reclaim (such as run by kswapd) is reclaiming XFS
inodes and issues a log force to unpin inodes that are dirty in the
CIL.
The CIL is pushed, but this will only occur once it gets the CIL
context lock to ensure that all committing transactions are complete
and no new transactions start being committed to the CIL while the
push switches to a new context.
The deadlock occurs when the CIL context lock is held by a
committing process that is doing memory allocation for log vector
buffers, and that allocation is then blocked on memory reclaim
making progress. Memory reclaim, however, is blocked waiting for
a log force to make progress, and so we effectively deadlock at this
point.
To solve this problem, we have to move the CIL log vector buffer
allocation outside of the context lock so that memory reclaim can
always make progress when it needs to force the log. The problem
with doing this is that a CIL push can take place while we are
determining if we need to allocate a new log vector buffer for
an item and hence the current log vector may go away without
warning. That means we canot rely on the existing log vector being
present when we finally grab the context lock and so we must have a
replacement buffer ready to go at all times.
To ensure this, introduce a "shadow log vector" buffer that is
always guaranteed to be present when we gain the CIL context lock
and format the item. This shadow buffer may or may not be used
during the formatting, but if the log item does not have an existing
log vector buffer or that buffer is too small for the new
modifications, we swap it for the new shadow buffer and format
the modifications into that new log vector buffer.
The result of this is that for any object we modify more than once
in a given CIL checkpoint, we double the memory required
to track dirty regions in the log. For single modifications then
we consume the shadow log vectorwe allocate on commit, and that gets
consumed by the checkpoint. However, if we make multiple
modifications, then the second transaction commit will allocate a
shadow log vector and hence we will end up with double the memory
usage as only one of the log vectors is consumed by the CIL
checkpoint. The remaining shadow vector will be freed when th elog
item is freed.
This can probably be optimised in future - access to the shadow log
vector is serialised by the object lock (as opposited to the active
log vector, which is controlled by the CIL context lock) and so we
can probably free shadow log vector from some objects when the log
item is marked clean on removal from the AIL.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-07-21 23:52:35 +00:00
|
|
|
kmem_free(efip->efi_item.li_lv_shadow);
|
2010-06-23 08:11:15 +00:00
|
|
|
if (efip->efi_format.efi_nextents > XFS_EFI_MAX_FAST_EXTENTS)
|
2008-05-19 06:31:57 +00:00
|
|
|
kmem_free(efip);
|
2010-06-23 08:11:15 +00:00
|
|
|
else
|
2019-11-14 20:43:04 +00:00
|
|
|
kmem_cache_free(xfs_efi_zone, efip);
|
2005-06-21 05:41:19 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-04-03 03:08:27 +00:00
|
|
|
/*
|
|
|
|
* Freeing the efi requires that we remove it from the AIL if it has already
|
|
|
|
* been placed there. However, the EFI may not yet have been placed in the AIL
|
|
|
|
* when called by xfs_efi_release() from EFD processing due to the ordering of
|
|
|
|
* committed vs unpin operations in bulk insert operations. Hence the reference
|
|
|
|
* count to ensure only the last caller frees the EFI.
|
|
|
|
*/
|
2020-05-01 23:00:50 +00:00
|
|
|
STATIC void
|
2018-04-03 03:08:27 +00:00
|
|
|
xfs_efi_release(
|
|
|
|
struct xfs_efi_log_item *efip)
|
|
|
|
{
|
|
|
|
ASSERT(atomic_read(&efip->efi_refcount) > 0);
|
|
|
|
if (atomic_dec_and_test(&efip->efi_refcount)) {
|
2020-05-06 20:25:23 +00:00
|
|
|
xfs_trans_ail_delete(&efip->efi_item, SHUTDOWN_LOG_IO_ERROR);
|
2018-04-03 03:08:27 +00:00
|
|
|
xfs_efi_item_free(efip);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* This returns the number of iovecs needed to log the given efi item.
|
|
|
|
* We only need 1 iovec for an efi item. It just logs the efi_log_format
|
|
|
|
* structure.
|
|
|
|
*/
|
2013-08-12 10:50:04 +00:00
|
|
|
static inline int
|
|
|
|
xfs_efi_item_sizeof(
|
|
|
|
struct xfs_efi_log_item *efip)
|
|
|
|
{
|
|
|
|
return sizeof(struct xfs_efi_log_format) +
|
|
|
|
(efip->efi_format.efi_nextents - 1) * sizeof(xfs_extent_t);
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efi_item_size(
|
2013-08-12 10:50:04 +00:00
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int *nvecs,
|
|
|
|
int *nbytes)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-08-12 10:50:04 +00:00
|
|
|
*nvecs += 1;
|
|
|
|
*nbytes += xfs_efi_item_sizeof(EFI_ITEM(lip));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is called to fill in the vector of log iovecs for the
|
|
|
|
* given efi log item. We use only 1 iovec, and we point that
|
|
|
|
* at the efi_log_format structure embedded in the efi item.
|
|
|
|
* It is at this point that we assert that all of the extent
|
|
|
|
* slots in the efi item have been filled.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efi_item_format(
|
|
|
|
struct xfs_log_item *lip,
|
2013-12-13 00:34:02 +00:00
|
|
|
struct xfs_log_vec *lv)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-06-23 08:11:15 +00:00
|
|
|
struct xfs_efi_log_item *efip = EFI_ITEM(lip);
|
2013-12-13 00:34:02 +00:00
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-12-20 00:59:49 +00:00
|
|
|
ASSERT(atomic_read(&efip->efi_next_extent) ==
|
|
|
|
efip->efi_format.efi_nextents);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
efip->efi_format.efi_type = XFS_LI_EFI;
|
|
|
|
efip->efi_format.efi_size = 1;
|
|
|
|
|
2013-12-13 00:34:02 +00:00
|
|
|
xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_EFI_FORMAT,
|
2013-12-13 00:00:43 +00:00
|
|
|
&efip->efi_format,
|
|
|
|
xfs_efi_item_sizeof(efip));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
xfs: fix efi/efd error handling to avoid fs shutdown hangs
Freeing an extent in XFS involves logging an EFI (extent free
intention), freeing the actual extent, and logging an EFD (extent
free done). The EFI object is created with a reference count of 2:
one for the current transaction and one for the subsequently created
EFD. Under normal circumstances, the first reference is dropped when
the EFI is unpinned and the second reference is dropped when the EFD
is committed to the on-disk log.
In event of errors or filesystem shutdown, there are various
potential cleanup scenarios depending on the state of the EFI/EFD.
The cleanup scenarios are confusing and racy, as demonstrated by the
following test sequence:
# mount $dev $mnt
# fsstress -d $mnt -n 99999 -p 16 -z -f fallocate=1 \
-f punch=1 -f creat=1 -f unlink=1 &
# sleep 5
# killall -9 fsstress; wait
# godown -f $mnt
# umount
... in which the final umount can hang due to the AIL being pinned
indefinitely by one or more EFI items. This can occur due to several
conditions. For example, if the shutdown occurs after the EFI is
committed to the on-disk log and the EFD committed to the CIL, but
before the EFD committed to the log, the EFD iop_committed() abort
handler does not drop its reference to the EFI. Alternatively,
manual error injection in the xfs_bmap_finish() codepath shows that
if an error occurs after the EFI transaction is committed but before
the EFD is constructed and logged, the EFI is never released from
the AIL.
Update the EFI/EFD item handling code to use a more straightforward
and reliable approach to error handling. If an error occurs after
the EFI transaction is committed and before the EFD is constructed,
release the EFI explicitly from xfs_bmap_finish(). If the EFI
transaction is cancelled, release the EFI in the unlock handler.
Once the EFD is constructed, it is responsible for releasing the EFI
under any circumstances (including whether the EFI item aborts due
to log I/O error). Update the EFD item handlers to release the EFI
if the transaction is cancelled or aborts due to log I/O error.
Finally, update xfs_bmap_finish() to log at least one EFD extent to
the transaction before xfs_free_extent() errors are handled to
ensure the transaction is dirty and EFD item error handling is
triggered.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-08-18 23:51:16 +00:00
|
|
|
* The unpin operation is the last place an EFI is manipulated in the log. It is
|
|
|
|
* either inserted in the AIL or aborted in the event of a log I/O error. In
|
|
|
|
* either case, the EFI transaction has been successfully committed to make it
|
|
|
|
* this far. Therefore, we expect whoever committed the EFI to either construct
|
|
|
|
* and commit the EFD or drop the EFD's reference in the event of error. Simply
|
|
|
|
* drop the log's EFI reference now that the log is done with it.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efi_item_unpin(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int remove)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-06-23 08:11:15 +00:00
|
|
|
struct xfs_efi_log_item *efip = EFI_ITEM(lip);
|
2015-08-18 23:50:12 +00:00
|
|
|
xfs_efi_release(efip);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
xfs: fix efi/efd error handling to avoid fs shutdown hangs
Freeing an extent in XFS involves logging an EFI (extent free
intention), freeing the actual extent, and logging an EFD (extent
free done). The EFI object is created with a reference count of 2:
one for the current transaction and one for the subsequently created
EFD. Under normal circumstances, the first reference is dropped when
the EFI is unpinned and the second reference is dropped when the EFD
is committed to the on-disk log.
In event of errors or filesystem shutdown, there are various
potential cleanup scenarios depending on the state of the EFI/EFD.
The cleanup scenarios are confusing and racy, as demonstrated by the
following test sequence:
# mount $dev $mnt
# fsstress -d $mnt -n 99999 -p 16 -z -f fallocate=1 \
-f punch=1 -f creat=1 -f unlink=1 &
# sleep 5
# killall -9 fsstress; wait
# godown -f $mnt
# umount
... in which the final umount can hang due to the AIL being pinned
indefinitely by one or more EFI items. This can occur due to several
conditions. For example, if the shutdown occurs after the EFI is
committed to the on-disk log and the EFD committed to the CIL, but
before the EFD committed to the log, the EFD iop_committed() abort
handler does not drop its reference to the EFI. Alternatively,
manual error injection in the xfs_bmap_finish() codepath shows that
if an error occurs after the EFI transaction is committed but before
the EFD is constructed and logged, the EFI is never released from
the AIL.
Update the EFI/EFD item handling code to use a more straightforward
and reliable approach to error handling. If an error occurs after
the EFI transaction is committed and before the EFD is constructed,
release the EFI explicitly from xfs_bmap_finish(). If the EFI
transaction is cancelled, release the EFI in the unlock handler.
Once the EFD is constructed, it is responsible for releasing the EFI
under any circumstances (including whether the EFI item aborts due
to log I/O error). Update the EFD item handlers to release the EFI
if the transaction is cancelled or aborts due to log I/O error.
Finally, update xfs_bmap_finish() to log at least one EFD extent to
the transaction before xfs_free_extent() errors are handled to
ensure the transaction is dirty and EFD item error handling is
triggered.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-08-18 23:51:16 +00:00
|
|
|
/*
|
|
|
|
* The EFI has been either committed or aborted if the transaction has been
|
|
|
|
* cancelled. If the transaction was cancelled, an EFD isn't going to be
|
|
|
|
* constructed and thus we free the EFI here directly.
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
STATIC void
|
2019-06-29 02:27:32 +00:00
|
|
|
xfs_efi_item_release(
|
2010-06-23 08:11:15 +00:00
|
|
|
struct xfs_log_item *lip)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2019-06-29 02:27:32 +00:00
|
|
|
xfs_efi_release(EFI_ITEM(lip));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate and initialize an efi item with the given number of extents.
|
|
|
|
*/
|
2020-05-01 23:00:48 +00:00
|
|
|
STATIC struct xfs_efi_log_item *
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efi_init(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
uint nextents)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
{
|
2010-06-23 08:11:15 +00:00
|
|
|
struct xfs_efi_log_item *efip;
|
2005-04-16 22:20:36 +00:00
|
|
|
uint size;
|
|
|
|
|
|
|
|
ASSERT(nextents > 0);
|
|
|
|
if (nextents > XFS_EFI_MAX_FAST_EXTENTS) {
|
2020-04-30 19:52:18 +00:00
|
|
|
size = (uint)(sizeof(struct xfs_efi_log_item) +
|
2005-04-16 22:20:36 +00:00
|
|
|
((nextents - 1) * sizeof(xfs_extent_t)));
|
2019-08-26 19:06:22 +00:00
|
|
|
efip = kmem_zalloc(size, 0);
|
2005-04-16 22:20:36 +00:00
|
|
|
} else {
|
2020-07-22 16:23:10 +00:00
|
|
|
efip = kmem_cache_zalloc(xfs_efi_zone,
|
|
|
|
GFP_KERNEL | __GFP_NOFAIL);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2010-03-22 23:10:00 +00:00
|
|
|
xfs_log_item_init(mp, &efip->efi_item, XFS_LI_EFI, &xfs_efi_item_ops);
|
2005-04-16 22:20:36 +00:00
|
|
|
efip->efi_format.efi_nextents = nextents;
|
2015-06-21 23:43:32 +00:00
|
|
|
efip->efi_format.efi_id = (uintptr_t)(void *)efip;
|
2010-12-20 00:59:49 +00:00
|
|
|
atomic_set(&efip->efi_next_extent, 0);
|
xfs: don't free EFIs before the EFDs are committed
Filesystems are occasionally being shut down with this error:
xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.
It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:
http://oss.sgi.com/archives/xfs/2013-01/msg00082.html
The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:
EFI EFI in AIL EFD Result
committed/unpinned Yes committed OK
committed/pinned No committed Shutdown
uncommitted No committed Shutdown
Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck. That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is *not* set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be
fine.
It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, and hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the
AIL.
What we really want is this: the EFI is always placed into the
AIL before the last reference goes away. The only way to guarantee
that is that the EFI is not freed until after it has been unpinned
*and* the EFD has been committed. That is, restructure the logic so
that the only case that can occur is the first case.
This can be done easily by replacing the XFS_EFI_COMMITTED with an
EFI reference count. The EFI is initialised with it's own count, and
that is not released until it is unpinned. However, there is a
complication to this method - the high level EFI/EFD code in
xfs_bmap_finish() does not hold direct references to the EFI
structure, and runs a transaction commit between the EFI and EFD
processing. Hence the EFI can be freed even before the EFD is
created using such a method.
Further, log recovery uses the AIL for tracking EFI/EFDs that need
to be recovered, but it uses the AIL *differently* to the EFI
transaction commit. Hence log recovery never pins or unpins EFIs, so
we can't drop the EFI reference count indirectly to free the EFI.
However, this doesn't prevent us from using a reference count here.
There is a 1:1 relationship between EFIs and EFDs, so when we
initialise the EFI we can take a reference count for the EFD as
well. This solves the xfs_bmap_finish() issue - the EFI will never
be freed until the EFD is processed. In terms of log recovery,
during the committing of the EFD we can look for the
XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
thereby ensuring everything works correctly there as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-04-03 03:09:21 +00:00
|
|
|
atomic_set(&efip->efi_refcount, 2);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-06-23 08:11:15 +00:00
|
|
|
return efip;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2006-06-09 04:55:38 +00:00
|
|
|
/*
|
|
|
|
* Copy an EFI format buffer from the given buf, and into the destination
|
|
|
|
* EFI format structure.
|
|
|
|
* The given buffer can be in 32 bit or 64 bit form (which has different padding),
|
|
|
|
* one of which will be the native format for this kernel.
|
|
|
|
* It will handle the conversion of formats if necessary.
|
|
|
|
*/
|
2020-05-01 23:00:48 +00:00
|
|
|
STATIC int
|
2006-06-09 04:55:38 +00:00
|
|
|
xfs_efi_copy_format(xfs_log_iovec_t *buf, xfs_efi_log_format_t *dst_efi_fmt)
|
|
|
|
{
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efi_log_format_t *src_efi_fmt = buf->i_addr;
|
2006-06-09 04:55:38 +00:00
|
|
|
uint i;
|
|
|
|
uint len = sizeof(xfs_efi_log_format_t) +
|
|
|
|
(src_efi_fmt->efi_nextents - 1) * sizeof(xfs_extent_t);
|
|
|
|
uint len32 = sizeof(xfs_efi_log_format_32_t) +
|
|
|
|
(src_efi_fmt->efi_nextents - 1) * sizeof(xfs_extent_32_t);
|
|
|
|
uint len64 = sizeof(xfs_efi_log_format_64_t) +
|
|
|
|
(src_efi_fmt->efi_nextents - 1) * sizeof(xfs_extent_64_t);
|
|
|
|
|
|
|
|
if (buf->i_len == len) {
|
|
|
|
memcpy((char *)dst_efi_fmt, (char*)src_efi_fmt, len);
|
|
|
|
return 0;
|
|
|
|
} else if (buf->i_len == len32) {
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efi_log_format_32_t *src_efi_fmt_32 = buf->i_addr;
|
2006-06-09 04:55:38 +00:00
|
|
|
|
|
|
|
dst_efi_fmt->efi_type = src_efi_fmt_32->efi_type;
|
|
|
|
dst_efi_fmt->efi_size = src_efi_fmt_32->efi_size;
|
|
|
|
dst_efi_fmt->efi_nextents = src_efi_fmt_32->efi_nextents;
|
|
|
|
dst_efi_fmt->efi_id = src_efi_fmt_32->efi_id;
|
|
|
|
for (i = 0; i < dst_efi_fmt->efi_nextents; i++) {
|
|
|
|
dst_efi_fmt->efi_extents[i].ext_start =
|
|
|
|
src_efi_fmt_32->efi_extents[i].ext_start;
|
|
|
|
dst_efi_fmt->efi_extents[i].ext_len =
|
|
|
|
src_efi_fmt_32->efi_extents[i].ext_len;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
} else if (buf->i_len == len64) {
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efi_log_format_64_t *src_efi_fmt_64 = buf->i_addr;
|
2006-06-09 04:55:38 +00:00
|
|
|
|
|
|
|
dst_efi_fmt->efi_type = src_efi_fmt_64->efi_type;
|
|
|
|
dst_efi_fmt->efi_size = src_efi_fmt_64->efi_size;
|
|
|
|
dst_efi_fmt->efi_nextents = src_efi_fmt_64->efi_nextents;
|
|
|
|
dst_efi_fmt->efi_id = src_efi_fmt_64->efi_id;
|
|
|
|
for (i = 0; i < dst_efi_fmt->efi_nextents; i++) {
|
|
|
|
dst_efi_fmt->efi_extents[i].ext_start =
|
|
|
|
src_efi_fmt_64->efi_extents[i].ext_start;
|
|
|
|
dst_efi_fmt->efi_extents[i].ext_len =
|
|
|
|
src_efi_fmt_64->efi_extents[i].ext_len;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2019-11-02 16:40:53 +00:00
|
|
|
XFS_ERROR_REPORT(__func__, XFS_ERRLEVEL_LOW, NULL);
|
2014-06-25 04:58:08 +00:00
|
|
|
return -EFSCORRUPTED;
|
2006-06-09 04:55:38 +00:00
|
|
|
}
|
|
|
|
|
2010-06-23 08:11:15 +00:00
|
|
|
static inline struct xfs_efd_log_item *EFD_ITEM(struct xfs_log_item *lip)
|
2005-06-21 05:41:19 +00:00
|
|
|
{
|
2010-06-23 08:11:15 +00:00
|
|
|
return container_of(lip, struct xfs_efd_log_item, efd_item);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-06-23 08:11:15 +00:00
|
|
|
STATIC void
|
|
|
|
xfs_efd_item_free(struct xfs_efd_log_item *efdp)
|
|
|
|
{
|
xfs: allocate log vector buffers outside CIL context lock
One of the problems we currently have with delayed logging is that
under serious memory pressure we can deadlock memory reclaim. THis
occurs when memory reclaim (such as run by kswapd) is reclaiming XFS
inodes and issues a log force to unpin inodes that are dirty in the
CIL.
The CIL is pushed, but this will only occur once it gets the CIL
context lock to ensure that all committing transactions are complete
and no new transactions start being committed to the CIL while the
push switches to a new context.
The deadlock occurs when the CIL context lock is held by a
committing process that is doing memory allocation for log vector
buffers, and that allocation is then blocked on memory reclaim
making progress. Memory reclaim, however, is blocked waiting for
a log force to make progress, and so we effectively deadlock at this
point.
To solve this problem, we have to move the CIL log vector buffer
allocation outside of the context lock so that memory reclaim can
always make progress when it needs to force the log. The problem
with doing this is that a CIL push can take place while we are
determining if we need to allocate a new log vector buffer for
an item and hence the current log vector may go away without
warning. That means we canot rely on the existing log vector being
present when we finally grab the context lock and so we must have a
replacement buffer ready to go at all times.
To ensure this, introduce a "shadow log vector" buffer that is
always guaranteed to be present when we gain the CIL context lock
and format the item. This shadow buffer may or may not be used
during the formatting, but if the log item does not have an existing
log vector buffer or that buffer is too small for the new
modifications, we swap it for the new shadow buffer and format
the modifications into that new log vector buffer.
The result of this is that for any object we modify more than once
in a given CIL checkpoint, we double the memory required
to track dirty regions in the log. For single modifications then
we consume the shadow log vectorwe allocate on commit, and that gets
consumed by the checkpoint. However, if we make multiple
modifications, then the second transaction commit will allocate a
shadow log vector and hence we will end up with double the memory
usage as only one of the log vectors is consumed by the CIL
checkpoint. The remaining shadow vector will be freed when th elog
item is freed.
This can probably be optimised in future - access to the shadow log
vector is serialised by the object lock (as opposited to the active
log vector, which is controlled by the CIL context lock) and so we
can probably free shadow log vector from some objects when the log
item is marked clean on removal from the AIL.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-07-21 23:52:35 +00:00
|
|
|
kmem_free(efdp->efd_item.li_lv_shadow);
|
2010-06-23 08:11:15 +00:00
|
|
|
if (efdp->efd_format.efd_nextents > XFS_EFD_MAX_FAST_EXTENTS)
|
2008-05-19 06:31:57 +00:00
|
|
|
kmem_free(efdp);
|
2010-06-23 08:11:15 +00:00
|
|
|
else
|
2019-11-14 20:43:04 +00:00
|
|
|
kmem_cache_free(xfs_efd_zone, efdp);
|
2005-06-21 05:41:19 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This returns the number of iovecs needed to log the given efd item.
|
|
|
|
* We only need 1 iovec for an efd item. It just logs the efd_log_format
|
|
|
|
* structure.
|
|
|
|
*/
|
2013-08-12 10:50:04 +00:00
|
|
|
static inline int
|
|
|
|
xfs_efd_item_sizeof(
|
|
|
|
struct xfs_efd_log_item *efdp)
|
|
|
|
{
|
|
|
|
return sizeof(xfs_efd_log_format_t) +
|
|
|
|
(efdp->efd_format.efd_nextents - 1) * sizeof(xfs_extent_t);
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efd_item_size(
|
2013-08-12 10:50:04 +00:00
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int *nvecs,
|
|
|
|
int *nbytes)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-08-12 10:50:04 +00:00
|
|
|
*nvecs += 1;
|
|
|
|
*nbytes += xfs_efd_item_sizeof(EFD_ITEM(lip));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is called to fill in the vector of log iovecs for the
|
|
|
|
* given efd log item. We use only 1 iovec, and we point that
|
|
|
|
* at the efd_log_format structure embedded in the efd item.
|
|
|
|
* It is at this point that we assert that all of the extent
|
|
|
|
* slots in the efd item have been filled.
|
|
|
|
*/
|
|
|
|
STATIC void
|
2010-06-23 08:11:15 +00:00
|
|
|
xfs_efd_item_format(
|
|
|
|
struct xfs_log_item *lip,
|
2013-12-13 00:34:02 +00:00
|
|
|
struct xfs_log_vec *lv)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-06-23 08:11:15 +00:00
|
|
|
struct xfs_efd_log_item *efdp = EFD_ITEM(lip);
|
2013-12-13 00:34:02 +00:00
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
ASSERT(efdp->efd_next_extent == efdp->efd_format.efd_nextents);
|
|
|
|
|
|
|
|
efdp->efd_format.efd_type = XFS_LI_EFD;
|
|
|
|
efdp->efd_format.efd_size = 1;
|
|
|
|
|
2013-12-13 00:34:02 +00:00
|
|
|
xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_EFD_FORMAT,
|
2013-12-13 00:00:43 +00:00
|
|
|
&efdp->efd_format,
|
|
|
|
xfs_efd_item_sizeof(efdp));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
xfs: fix efi/efd error handling to avoid fs shutdown hangs
Freeing an extent in XFS involves logging an EFI (extent free
intention), freeing the actual extent, and logging an EFD (extent
free done). The EFI object is created with a reference count of 2:
one for the current transaction and one for the subsequently created
EFD. Under normal circumstances, the first reference is dropped when
the EFI is unpinned and the second reference is dropped when the EFD
is committed to the on-disk log.
In event of errors or filesystem shutdown, there are various
potential cleanup scenarios depending on the state of the EFI/EFD.
The cleanup scenarios are confusing and racy, as demonstrated by the
following test sequence:
# mount $dev $mnt
# fsstress -d $mnt -n 99999 -p 16 -z -f fallocate=1 \
-f punch=1 -f creat=1 -f unlink=1 &
# sleep 5
# killall -9 fsstress; wait
# godown -f $mnt
# umount
... in which the final umount can hang due to the AIL being pinned
indefinitely by one or more EFI items. This can occur due to several
conditions. For example, if the shutdown occurs after the EFI is
committed to the on-disk log and the EFD committed to the CIL, but
before the EFD committed to the log, the EFD iop_committed() abort
handler does not drop its reference to the EFI. Alternatively,
manual error injection in the xfs_bmap_finish() codepath shows that
if an error occurs after the EFI transaction is committed but before
the EFD is constructed and logged, the EFI is never released from
the AIL.
Update the EFI/EFD item handling code to use a more straightforward
and reliable approach to error handling. If an error occurs after
the EFI transaction is committed and before the EFD is constructed,
release the EFI explicitly from xfs_bmap_finish(). If the EFI
transaction is cancelled, release the EFI in the unlock handler.
Once the EFD is constructed, it is responsible for releasing the EFI
under any circumstances (including whether the EFI item aborts due
to log I/O error). Update the EFD item handlers to release the EFI
if the transaction is cancelled or aborts due to log I/O error.
Finally, update xfs_bmap_finish() to log at least one EFD extent to
the transaction before xfs_free_extent() errors are handled to
ensure the transaction is dirty and EFD item error handling is
triggered.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-08-18 23:51:16 +00:00
|
|
|
/*
|
|
|
|
* The EFD is either committed or aborted if the transaction is cancelled. If
|
|
|
|
* the transaction is cancelled, drop our reference to the EFI and free the EFD.
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
STATIC void
|
2019-06-29 02:27:32 +00:00
|
|
|
xfs_efd_item_release(
|
2010-06-23 08:11:15 +00:00
|
|
|
struct xfs_log_item *lip)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
xfs: fix efi/efd error handling to avoid fs shutdown hangs
Freeing an extent in XFS involves logging an EFI (extent free
intention), freeing the actual extent, and logging an EFD (extent
free done). The EFI object is created with a reference count of 2:
one for the current transaction and one for the subsequently created
EFD. Under normal circumstances, the first reference is dropped when
the EFI is unpinned and the second reference is dropped when the EFD
is committed to the on-disk log.
In event of errors or filesystem shutdown, there are various
potential cleanup scenarios depending on the state of the EFI/EFD.
The cleanup scenarios are confusing and racy, as demonstrated by the
following test sequence:
# mount $dev $mnt
# fsstress -d $mnt -n 99999 -p 16 -z -f fallocate=1 \
-f punch=1 -f creat=1 -f unlink=1 &
# sleep 5
# killall -9 fsstress; wait
# godown -f $mnt
# umount
... in which the final umount can hang due to the AIL being pinned
indefinitely by one or more EFI items. This can occur due to several
conditions. For example, if the shutdown occurs after the EFI is
committed to the on-disk log and the EFD committed to the CIL, but
before the EFD committed to the log, the EFD iop_committed() abort
handler does not drop its reference to the EFI. Alternatively,
manual error injection in the xfs_bmap_finish() codepath shows that
if an error occurs after the EFI transaction is committed but before
the EFD is constructed and logged, the EFI is never released from
the AIL.
Update the EFI/EFD item handling code to use a more straightforward
and reliable approach to error handling. If an error occurs after
the EFI transaction is committed and before the EFD is constructed,
release the EFI explicitly from xfs_bmap_finish(). If the EFI
transaction is cancelled, release the EFI in the unlock handler.
Once the EFD is constructed, it is responsible for releasing the EFI
under any circumstances (including whether the EFI item aborts due
to log I/O error). Update the EFD item handlers to release the EFI
if the transaction is cancelled or aborts due to log I/O error.
Finally, update xfs_bmap_finish() to log at least one EFD extent to
the transaction before xfs_free_extent() errors are handled to
ensure the transaction is dirty and EFD item error handling is
triggered.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-08-18 23:51:16 +00:00
|
|
|
struct xfs_efd_log_item *efdp = EFD_ITEM(lip);
|
|
|
|
|
2019-06-29 02:27:32 +00:00
|
|
|
xfs_efi_release(efdp->efd_efip);
|
|
|
|
xfs_efd_item_free(efdp);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2011-10-28 09:54:24 +00:00
|
|
|
static const struct xfs_item_ops xfs_efd_item_ops = {
|
2019-06-29 02:27:32 +00:00
|
|
|
.flags = XFS_ITEM_RELEASE_WHEN_COMMITTED,
|
2010-06-23 08:11:15 +00:00
|
|
|
.iop_size = xfs_efd_item_size,
|
|
|
|
.iop_format = xfs_efd_item_format,
|
2019-06-29 02:27:32 +00:00
|
|
|
.iop_release = xfs_efd_item_release,
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2019-06-29 02:27:35 +00:00
|
|
|
* Allocate an "extent free done" log item that will hold nextents worth of
|
|
|
|
* extents. The caller must use all nextents extents, because we are not
|
|
|
|
* flexible about this at all.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2019-06-29 02:28:17 +00:00
|
|
|
static struct xfs_efd_log_item *
|
2019-06-29 02:27:35 +00:00
|
|
|
xfs_trans_get_efd(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_efi_log_item *efip,
|
|
|
|
unsigned int nextents)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2019-06-29 02:27:35 +00:00
|
|
|
struct xfs_efd_log_item *efdp;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
ASSERT(nextents > 0);
|
2019-06-29 02:27:35 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (nextents > XFS_EFD_MAX_FAST_EXTENTS) {
|
2019-06-29 02:27:35 +00:00
|
|
|
efdp = kmem_zalloc(sizeof(struct xfs_efd_log_item) +
|
|
|
|
(nextents - 1) * sizeof(struct xfs_extent),
|
2019-08-26 19:06:22 +00:00
|
|
|
0);
|
2005-04-16 22:20:36 +00:00
|
|
|
} else {
|
2020-07-22 16:23:10 +00:00
|
|
|
efdp = kmem_cache_zalloc(xfs_efd_zone,
|
|
|
|
GFP_KERNEL | __GFP_NOFAIL);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2019-06-29 02:27:35 +00:00
|
|
|
xfs_log_item_init(tp->t_mountp, &efdp->efd_item, XFS_LI_EFD,
|
|
|
|
&xfs_efd_item_ops);
|
2005-04-16 22:20:36 +00:00
|
|
|
efdp->efd_efip = efip;
|
|
|
|
efdp->efd_format.efd_nextents = nextents;
|
|
|
|
efdp->efd_format.efd_efi_id = efip->efi_format.efi_id;
|
|
|
|
|
2019-06-29 02:27:35 +00:00
|
|
|
xfs_trans_add_item(tp, &efdp->efd_item);
|
2010-06-23 08:11:15 +00:00
|
|
|
return efdp;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2016-08-03 01:23:49 +00:00
|
|
|
|
2019-06-29 02:28:17 +00:00
|
|
|
/*
|
|
|
|
* Free an extent and log it to the EFD. Note that the transaction is marked
|
|
|
|
* dirty regardless of whether the extent free succeeds or fails to support the
|
|
|
|
* EFI/EFD lifecycle rules.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
xfs_trans_free_extent(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_efd_log_item *efdp,
|
|
|
|
xfs_fsblock_t start_block,
|
|
|
|
xfs_extlen_t ext_len,
|
|
|
|
const struct xfs_owner_info *oinfo,
|
|
|
|
bool skip_discard)
|
|
|
|
{
|
|
|
|
struct xfs_mount *mp = tp->t_mountp;
|
|
|
|
struct xfs_extent *extp;
|
|
|
|
uint next_extent;
|
|
|
|
xfs_agnumber_t agno = XFS_FSB_TO_AGNO(mp, start_block);
|
|
|
|
xfs_agblock_t agbno = XFS_FSB_TO_AGBNO(mp,
|
|
|
|
start_block);
|
|
|
|
int error;
|
|
|
|
|
|
|
|
trace_xfs_bmap_free_deferred(tp->t_mountp, agno, 0, agbno, ext_len);
|
|
|
|
|
|
|
|
error = __xfs_free_extent(tp, start_block, ext_len,
|
|
|
|
oinfo, XFS_AG_RESV_NONE, skip_discard);
|
|
|
|
/*
|
|
|
|
* Mark the transaction dirty, even on error. This ensures the
|
|
|
|
* transaction is aborted, which:
|
|
|
|
*
|
|
|
|
* 1.) releases the EFI and frees the EFD
|
|
|
|
* 2.) shuts down the filesystem
|
|
|
|
*/
|
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY;
|
|
|
|
set_bit(XFS_LI_DIRTY, &efdp->efd_item.li_flags);
|
|
|
|
|
|
|
|
next_extent = efdp->efd_next_extent;
|
|
|
|
ASSERT(next_extent < efdp->efd_format.efd_nextents);
|
|
|
|
extp = &(efdp->efd_format.efd_extents[next_extent]);
|
|
|
|
extp->ext_start = start_block;
|
|
|
|
extp->ext_len = ext_len;
|
|
|
|
efdp->efd_next_extent++;
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Sort bmap items by AG. */
|
|
|
|
static int
|
|
|
|
xfs_extent_free_diff_items(
|
|
|
|
void *priv,
|
2021-04-08 18:28:34 +00:00
|
|
|
const struct list_head *a,
|
|
|
|
const struct list_head *b)
|
2019-06-29 02:28:17 +00:00
|
|
|
{
|
|
|
|
struct xfs_mount *mp = priv;
|
|
|
|
struct xfs_extent_free_item *ra;
|
|
|
|
struct xfs_extent_free_item *rb;
|
|
|
|
|
|
|
|
ra = container_of(a, struct xfs_extent_free_item, xefi_list);
|
|
|
|
rb = container_of(b, struct xfs_extent_free_item, xefi_list);
|
|
|
|
return XFS_FSB_TO_AGNO(mp, ra->xefi_startblock) -
|
|
|
|
XFS_FSB_TO_AGNO(mp, rb->xefi_startblock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Log a free extent to the intent item. */
|
|
|
|
STATIC void
|
|
|
|
xfs_extent_free_log_item(
|
|
|
|
struct xfs_trans *tp,
|
2020-04-30 19:52:20 +00:00
|
|
|
struct xfs_efi_log_item *efip,
|
|
|
|
struct xfs_extent_free_item *free)
|
2019-06-29 02:28:17 +00:00
|
|
|
{
|
|
|
|
uint next_extent;
|
|
|
|
struct xfs_extent *extp;
|
|
|
|
|
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY;
|
|
|
|
set_bit(XFS_LI_DIRTY, &efip->efi_item.li_flags);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* atomic_inc_return gives us the value after the increment;
|
|
|
|
* we want to use it as an array index so we need to subtract 1 from
|
|
|
|
* it.
|
|
|
|
*/
|
|
|
|
next_extent = atomic_inc_return(&efip->efi_next_extent) - 1;
|
|
|
|
ASSERT(next_extent < efip->efi_format.efi_nextents);
|
|
|
|
extp = &efip->efi_format.efi_extents[next_extent];
|
|
|
|
extp->ext_start = free->xefi_startblock;
|
|
|
|
extp->ext_len = free->xefi_blockcount;
|
|
|
|
}
|
|
|
|
|
2020-04-30 19:52:21 +00:00
|
|
|
static struct xfs_log_item *
|
2020-04-30 19:52:20 +00:00
|
|
|
xfs_extent_free_create_intent(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct list_head *items,
|
2020-04-30 19:52:20 +00:00
|
|
|
unsigned int count,
|
|
|
|
bool sort)
|
2020-04-30 19:52:20 +00:00
|
|
|
{
|
|
|
|
struct xfs_mount *mp = tp->t_mountp;
|
|
|
|
struct xfs_efi_log_item *efip = xfs_efi_init(mp, count);
|
|
|
|
struct xfs_extent_free_item *free;
|
|
|
|
|
|
|
|
ASSERT(count > 0);
|
|
|
|
|
|
|
|
xfs_trans_add_item(tp, &efip->efi_item);
|
2020-04-30 19:52:20 +00:00
|
|
|
if (sort)
|
|
|
|
list_sort(mp, items, xfs_extent_free_diff_items);
|
2020-04-30 19:52:20 +00:00
|
|
|
list_for_each_entry(free, items, xefi_list)
|
|
|
|
xfs_extent_free_log_item(tp, efip, free);
|
2020-04-30 19:52:21 +00:00
|
|
|
return &efip->efi_item;
|
2020-04-30 19:52:20 +00:00
|
|
|
}
|
|
|
|
|
2019-06-29 02:28:17 +00:00
|
|
|
/* Get an EFD so we can process all the free extents. */
|
2020-04-30 19:52:22 +00:00
|
|
|
static struct xfs_log_item *
|
2019-06-29 02:28:17 +00:00
|
|
|
xfs_extent_free_create_done(
|
|
|
|
struct xfs_trans *tp,
|
2020-04-30 19:52:21 +00:00
|
|
|
struct xfs_log_item *intent,
|
2019-06-29 02:28:17 +00:00
|
|
|
unsigned int count)
|
|
|
|
{
|
2020-04-30 19:52:22 +00:00
|
|
|
return &xfs_trans_get_efd(tp, EFI_ITEM(intent), count)->efd_item;
|
2019-06-29 02:28:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Process a free extent. */
|
|
|
|
STATIC int
|
|
|
|
xfs_extent_free_finish_item(
|
|
|
|
struct xfs_trans *tp,
|
2020-04-30 19:52:22 +00:00
|
|
|
struct xfs_log_item *done,
|
2019-06-29 02:28:17 +00:00
|
|
|
struct list_head *item,
|
2020-04-30 19:52:22 +00:00
|
|
|
struct xfs_btree_cur **state)
|
2019-06-29 02:28:17 +00:00
|
|
|
{
|
|
|
|
struct xfs_extent_free_item *free;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
free = container_of(item, struct xfs_extent_free_item, xefi_list);
|
2020-04-30 19:52:22 +00:00
|
|
|
error = xfs_trans_free_extent(tp, EFD_ITEM(done),
|
2019-06-29 02:28:17 +00:00
|
|
|
free->xefi_startblock,
|
|
|
|
free->xefi_blockcount,
|
|
|
|
&free->xefi_oinfo, free->xefi_skip_discard);
|
|
|
|
kmem_free(free);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Abort all pending EFIs. */
|
|
|
|
STATIC void
|
|
|
|
xfs_extent_free_abort_intent(
|
2020-04-30 19:52:21 +00:00
|
|
|
struct xfs_log_item *intent)
|
2019-06-29 02:28:17 +00:00
|
|
|
{
|
2020-04-30 19:52:21 +00:00
|
|
|
xfs_efi_release(EFI_ITEM(intent));
|
2019-06-29 02:28:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Cancel a free extent. */
|
|
|
|
STATIC void
|
|
|
|
xfs_extent_free_cancel_item(
|
|
|
|
struct list_head *item)
|
|
|
|
{
|
|
|
|
struct xfs_extent_free_item *free;
|
|
|
|
|
|
|
|
free = container_of(item, struct xfs_extent_free_item, xefi_list);
|
|
|
|
kmem_free(free);
|
|
|
|
}
|
|
|
|
|
|
|
|
const struct xfs_defer_op_type xfs_extent_free_defer_type = {
|
|
|
|
.max_items = XFS_EFI_MAX_FAST_EXTENTS,
|
|
|
|
.create_intent = xfs_extent_free_create_intent,
|
|
|
|
.abort_intent = xfs_extent_free_abort_intent,
|
|
|
|
.create_done = xfs_extent_free_create_done,
|
|
|
|
.finish_item = xfs_extent_free_finish_item,
|
|
|
|
.cancel_item = xfs_extent_free_cancel_item,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* AGFL blocks are accounted differently in the reserve pools and are not
|
|
|
|
* inserted into the busy extent list.
|
|
|
|
*/
|
|
|
|
STATIC int
|
|
|
|
xfs_agfl_free_finish_item(
|
|
|
|
struct xfs_trans *tp,
|
2020-04-30 19:52:22 +00:00
|
|
|
struct xfs_log_item *done,
|
2019-06-29 02:28:17 +00:00
|
|
|
struct list_head *item,
|
2020-04-30 19:52:22 +00:00
|
|
|
struct xfs_btree_cur **state)
|
2019-06-29 02:28:17 +00:00
|
|
|
{
|
|
|
|
struct xfs_mount *mp = tp->t_mountp;
|
2020-04-30 19:52:22 +00:00
|
|
|
struct xfs_efd_log_item *efdp = EFD_ITEM(done);
|
2019-06-29 02:28:17 +00:00
|
|
|
struct xfs_extent_free_item *free;
|
|
|
|
struct xfs_extent *extp;
|
|
|
|
struct xfs_buf *agbp;
|
|
|
|
int error;
|
|
|
|
xfs_agnumber_t agno;
|
|
|
|
xfs_agblock_t agbno;
|
|
|
|
uint next_extent;
|
|
|
|
|
|
|
|
free = container_of(item, struct xfs_extent_free_item, xefi_list);
|
|
|
|
ASSERT(free->xefi_blockcount == 1);
|
|
|
|
agno = XFS_FSB_TO_AGNO(mp, free->xefi_startblock);
|
|
|
|
agbno = XFS_FSB_TO_AGBNO(mp, free->xefi_startblock);
|
|
|
|
|
|
|
|
trace_xfs_agfl_free_deferred(mp, agno, 0, agbno, free->xefi_blockcount);
|
|
|
|
|
|
|
|
error = xfs_alloc_read_agf(mp, tp, agno, 0, &agbp);
|
|
|
|
if (!error)
|
|
|
|
error = xfs_free_agfl_block(tp, agno, agbno, agbp,
|
|
|
|
&free->xefi_oinfo);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mark the transaction dirty, even on error. This ensures the
|
|
|
|
* transaction is aborted, which:
|
|
|
|
*
|
|
|
|
* 1.) releases the EFI and frees the EFD
|
|
|
|
* 2.) shuts down the filesystem
|
|
|
|
*/
|
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY;
|
|
|
|
set_bit(XFS_LI_DIRTY, &efdp->efd_item.li_flags);
|
|
|
|
|
|
|
|
next_extent = efdp->efd_next_extent;
|
|
|
|
ASSERT(next_extent < efdp->efd_format.efd_nextents);
|
|
|
|
extp = &(efdp->efd_format.efd_extents[next_extent]);
|
|
|
|
extp->ext_start = free->xefi_startblock;
|
|
|
|
extp->ext_len = free->xefi_blockcount;
|
|
|
|
efdp->efd_next_extent++;
|
|
|
|
|
|
|
|
kmem_free(free);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* sub-type with special handling for AGFL deferred frees */
|
|
|
|
const struct xfs_defer_op_type xfs_agfl_free_defer_type = {
|
|
|
|
.max_items = XFS_EFI_MAX_FAST_EXTENTS,
|
|
|
|
.create_intent = xfs_extent_free_create_intent,
|
|
|
|
.abort_intent = xfs_extent_free_abort_intent,
|
|
|
|
.create_done = xfs_extent_free_create_done,
|
|
|
|
.finish_item = xfs_agfl_free_finish_item,
|
|
|
|
.cancel_item = xfs_extent_free_cancel_item,
|
|
|
|
};
|
|
|
|
|
2020-11-30 00:33:38 +00:00
|
|
|
/* Is this recovered EFI ok? */
|
|
|
|
static inline bool
|
|
|
|
xfs_efi_validate_ext(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct xfs_extent *extp)
|
|
|
|
{
|
2020-12-04 21:20:00 +00:00
|
|
|
return xfs_verify_fsbext(mp, extp->ext_start, extp->ext_len);
|
2020-11-30 00:33:38 +00:00
|
|
|
}
|
|
|
|
|
2016-08-03 01:23:49 +00:00
|
|
|
/*
|
|
|
|
* Process an extent free intent item that was recovered from
|
|
|
|
* the log. We need to free the extents that it describes.
|
|
|
|
*/
|
2020-05-01 23:00:50 +00:00
|
|
|
STATIC int
|
2020-05-01 23:00:55 +00:00
|
|
|
xfs_efi_item_recover(
|
|
|
|
struct xfs_log_item *lip,
|
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 00:39:37 +00:00
|
|
|
struct list_head *capture_list)
|
2016-08-03 01:23:49 +00:00
|
|
|
{
|
2020-05-01 23:00:55 +00:00
|
|
|
struct xfs_efi_log_item *efip = EFI_ITEM(lip);
|
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 00:39:37 +00:00
|
|
|
struct xfs_mount *mp = lip->li_mountp;
|
2020-05-01 23:00:55 +00:00
|
|
|
struct xfs_efd_log_item *efdp;
|
|
|
|
struct xfs_trans *tp;
|
|
|
|
struct xfs_extent *extp;
|
|
|
|
int i;
|
|
|
|
int error = 0;
|
2016-08-03 01:23:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* First check the validity of the extents described by the
|
|
|
|
* EFI. If any are bad, then assume that all are bad and
|
|
|
|
* just toss the EFI.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < efip->efi_format.efi_nextents; i++) {
|
2020-11-30 00:33:38 +00:00
|
|
|
if (!xfs_efi_validate_ext(mp,
|
|
|
|
&efip->efi_format.efi_extents[i])) {
|
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
&efip->efi_format,
|
|
|
|
sizeof(efip->efi_format));
|
2019-11-06 17:17:43 +00:00
|
|
|
return -EFSCORRUPTED;
|
2020-11-30 00:33:38 +00:00
|
|
|
}
|
2016-08-03 01:23:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
error = xfs_trans_alloc(mp, &M_RES(mp)->tr_itruncate, 0, 0, 0, &tp);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
efdp = xfs_trans_get_efd(tp, efip, efip->efi_format.efi_nextents);
|
|
|
|
|
|
|
|
for (i = 0; i < efip->efi_format.efi_nextents; i++) {
|
2016-08-03 02:29:32 +00:00
|
|
|
extp = &efip->efi_format.efi_extents[i];
|
2016-08-03 01:23:49 +00:00
|
|
|
error = xfs_trans_free_extent(tp, efdp, extp->ext_start,
|
2018-12-12 16:46:23 +00:00
|
|
|
extp->ext_len,
|
|
|
|
&XFS_RMAP_OINFO_ANY_OWNER, false);
|
2021-08-06 18:06:35 +00:00
|
|
|
if (error == -EFSCORRUPTED)
|
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
extp, sizeof(*extp));
|
2016-08-03 01:23:49 +00:00
|
|
|
if (error)
|
|
|
|
goto abort_error;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2020-09-26 00:39:51 +00:00
|
|
|
return xfs_defer_ops_capture_and_commit(tp, NULL, capture_list);
|
2016-08-03 01:23:49 +00:00
|
|
|
|
|
|
|
abort_error:
|
|
|
|
xfs_trans_cancel(tp);
|
|
|
|
return error;
|
|
|
|
}
|
2020-05-01 23:00:45 +00:00
|
|
|
|
2020-05-01 23:00:54 +00:00
|
|
|
STATIC bool
|
|
|
|
xfs_efi_item_match(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
uint64_t intent_id)
|
|
|
|
{
|
|
|
|
return EFI_ITEM(lip)->efi_format.efi_id == intent_id;
|
|
|
|
}
|
|
|
|
|
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-27 23:18:13 +00:00
|
|
|
/* Relog an intent item to push the log tail forward. */
|
|
|
|
static struct xfs_log_item *
|
|
|
|
xfs_efi_item_relog(
|
|
|
|
struct xfs_log_item *intent,
|
|
|
|
struct xfs_trans *tp)
|
|
|
|
{
|
|
|
|
struct xfs_efd_log_item *efdp;
|
|
|
|
struct xfs_efi_log_item *efip;
|
|
|
|
struct xfs_extent *extp;
|
|
|
|
unsigned int count;
|
|
|
|
|
|
|
|
count = EFI_ITEM(intent)->efi_format.efi_nextents;
|
|
|
|
extp = EFI_ITEM(intent)->efi_format.efi_extents;
|
|
|
|
|
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY;
|
|
|
|
efdp = xfs_trans_get_efd(tp, EFI_ITEM(intent), count);
|
|
|
|
efdp->efd_next_extent = count;
|
|
|
|
memcpy(efdp->efd_format.efd_extents, extp, count * sizeof(*extp));
|
|
|
|
set_bit(XFS_LI_DIRTY, &efdp->efd_item.li_flags);
|
|
|
|
|
|
|
|
efip = xfs_efi_init(tp->t_mountp, count);
|
|
|
|
memcpy(efip->efi_format.efi_extents, extp, count * sizeof(*extp));
|
|
|
|
atomic_set(&efip->efi_next_extent, count);
|
|
|
|
xfs_trans_add_item(tp, &efip->efi_item);
|
|
|
|
set_bit(XFS_LI_DIRTY, &efip->efi_item.li_flags);
|
|
|
|
return &efip->efi_item;
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:50 +00:00
|
|
|
static const struct xfs_item_ops xfs_efi_item_ops = {
|
|
|
|
.iop_size = xfs_efi_item_size,
|
|
|
|
.iop_format = xfs_efi_item_format,
|
|
|
|
.iop_unpin = xfs_efi_item_unpin,
|
|
|
|
.iop_release = xfs_efi_item_release,
|
|
|
|
.iop_recover = xfs_efi_item_recover,
|
2020-05-01 23:00:54 +00:00
|
|
|
.iop_match = xfs_efi_item_match,
|
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-27 23:18:13 +00:00
|
|
|
.iop_relog = xfs_efi_item_relog,
|
2020-05-01 23:00:50 +00:00
|
|
|
};
|
|
|
|
|
2020-05-01 23:00:48 +00:00
|
|
|
/*
|
|
|
|
* This routine is called to create an in-core extent free intent
|
|
|
|
* item from the efi format structure which was logged on disk.
|
|
|
|
* It allocates an in-core efi, copies the extents from the format
|
|
|
|
* structure into it, and adds the efi to the AIL with the given
|
|
|
|
* LSN.
|
|
|
|
*/
|
|
|
|
STATIC int
|
|
|
|
xlog_recover_efi_commit_pass2(
|
|
|
|
struct xlog *log,
|
|
|
|
struct list_head *buffer_list,
|
|
|
|
struct xlog_recover_item *item,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
struct xfs_mount *mp = log->l_mp;
|
|
|
|
struct xfs_efi_log_item *efip;
|
|
|
|
struct xfs_efi_log_format *efi_formatp;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
efi_formatp = item->ri_buf[0].i_addr;
|
|
|
|
|
|
|
|
efip = xfs_efi_init(mp, efi_formatp->efi_nextents);
|
|
|
|
error = xfs_efi_copy_format(&item->ri_buf[0], &efip->efi_format);
|
|
|
|
if (error) {
|
|
|
|
xfs_efi_item_free(efip);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
atomic_set(&efip->efi_next_extent, efi_formatp->efi_nextents);
|
|
|
|
/*
|
2020-05-01 23:00:54 +00:00
|
|
|
* Insert the intent into the AIL directly and drop one reference so
|
|
|
|
* that finishing or canceling the work will drop the other.
|
2020-05-01 23:00:48 +00:00
|
|
|
*/
|
2020-05-01 23:00:54 +00:00
|
|
|
xfs_trans_ail_insert(log->l_ailp, &efip->efi_item, lsn);
|
2020-05-01 23:00:48 +00:00
|
|
|
xfs_efi_release(efip);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:45 +00:00
|
|
|
const struct xlog_recover_item_ops xlog_efi_item_ops = {
|
|
|
|
.item_type = XFS_LI_EFI,
|
2020-05-01 23:00:48 +00:00
|
|
|
.commit_pass2 = xlog_recover_efi_commit_pass2,
|
2020-05-01 23:00:45 +00:00
|
|
|
};
|
|
|
|
|
2020-05-01 23:00:48 +00:00
|
|
|
/*
|
|
|
|
* This routine is called when an EFD format structure is found in a committed
|
|
|
|
* transaction in the log. Its purpose is to cancel the corresponding EFI if it
|
|
|
|
* was still in the log. To do this it searches the AIL for the EFI with an id
|
|
|
|
* equal to that in the EFD format structure. If we find it we drop the EFD
|
|
|
|
* reference, which removes the EFI from the AIL and frees it.
|
|
|
|
*/
|
|
|
|
STATIC int
|
|
|
|
xlog_recover_efd_commit_pass2(
|
|
|
|
struct xlog *log,
|
|
|
|
struct list_head *buffer_list,
|
|
|
|
struct xlog_recover_item *item,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
struct xfs_efd_log_format *efd_formatp;
|
|
|
|
|
|
|
|
efd_formatp = item->ri_buf[0].i_addr;
|
|
|
|
ASSERT((item->ri_buf[0].i_len == (sizeof(xfs_efd_log_format_32_t) +
|
|
|
|
((efd_formatp->efd_nextents - 1) * sizeof(xfs_extent_32_t)))) ||
|
|
|
|
(item->ri_buf[0].i_len == (sizeof(xfs_efd_log_format_64_t) +
|
|
|
|
((efd_formatp->efd_nextents - 1) * sizeof(xfs_extent_64_t)))));
|
|
|
|
|
2020-05-01 23:00:54 +00:00
|
|
|
xlog_recover_release_intent(log, XFS_LI_EFI, efd_formatp->efd_efi_id);
|
2020-05-01 23:00:48 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-01 23:00:45 +00:00
|
|
|
const struct xlog_recover_item_ops xlog_efd_item_ops = {
|
|
|
|
.item_type = XFS_LI_EFD,
|
2020-05-01 23:00:48 +00:00
|
|
|
.commit_pass2 = xlog_recover_efd_commit_pass2,
|
2020-05-01 23:00:45 +00:00
|
|
|
};
|