2018-06-06 10:42:14 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2005-11-02 11:58:39 +08:00
|
|
|
* Copyright (c) 2000-2005 Silicon Graphics, Inc.
|
|
|
|
|
* All Rights Reserved.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
#include "xfs.h"
|
2005-11-02 11:38:42 +08:00
|
|
|
#include "xfs_fs.h"
|
2019-06-29 10:25:35 +08:00
|
|
|
#include "xfs_shared.h"
|
2014-11-28 11:25:04 +08:00
|
|
|
#include "xfs_format.h"
|
2013-10-23 07:50:10 +08:00
|
|
|
#include "xfs_log_format.h"
|
|
|
|
|
#include "xfs_trans_resv.h"
|
2005-11-02 11:38:42 +08:00
|
|
|
#include "xfs_bit.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
#include "xfs_mount.h"
|
2013-10-23 07:50:10 +08:00
|
|
|
#include "xfs_trans.h"
|
2020-06-30 05:49:15 +08:00
|
|
|
#include "xfs_trans_priv.h"
|
2005-11-02 11:38:42 +08:00
|
|
|
#include "xfs_buf_item.h"
|
2020-06-30 05:48:48 +08:00
|
|
|
#include "xfs_inode.h"
|
|
|
|
|
#include "xfs_inode_item.h"
|
2020-06-30 05:48:59 +08:00
|
|
|
#include "xfs_quota.h"
|
|
|
|
|
#include "xfs_dquot_item.h"
|
|
|
|
|
#include "xfs_dquot.h"
|
2009-12-15 07:14:59 +08:00
|
|
|
#include "xfs_trace.h"
|
2013-10-23 07:50:10 +08:00
|
|
|
#include "xfs_log.h"
|
2022-03-18 00:09:12 +08:00
|
|
|
#include "xfs_log_priv.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
|
2021-10-13 02:09:23 +08:00
|
|
|
struct kmem_cache *xfs_buf_item_cache;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-06-23 16:11:15 +08:00
|
|
|
static inline struct xfs_buf_log_item *BUF_ITEM(struct xfs_log_item *lip)
|
|
|
|
|
{
|
|
|
|
|
return container_of(lip, struct xfs_buf_log_item, bli_item);
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-14 08:33:46 +08:00
|
|
|
/* Is this log iovec plausibly large enough to contain the buffer log format? */
|
|
|
|
|
bool
|
|
|
|
|
xfs_buf_log_check_iovec(
|
|
|
|
|
struct xfs_log_iovec *iovec)
|
|
|
|
|
{
|
|
|
|
|
struct xfs_buf_log_format *blfp = iovec->i_addr;
|
|
|
|
|
char *bmp_end;
|
|
|
|
|
char *item_end;
|
|
|
|
|
|
|
|
|
|
if (offsetof(struct xfs_buf_log_format, blf_data_map) > iovec->i_len)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
item_end = (char *)iovec->i_addr + iovec->i_len;
|
|
|
|
|
bmp_end = (char *)&blfp->blf_data_map[blfp->blf_map_size];
|
|
|
|
|
return bmp_end <= item_end;
|
|
|
|
|
}
|
|
|
|
|
|
2013-08-12 18:50:04 +08:00
|
|
|
static inline int
|
|
|
|
|
xfs_buf_log_format_size(
|
|
|
|
|
struct xfs_buf_log_format *blfp)
|
|
|
|
|
{
|
|
|
|
|
return offsetof(struct xfs_buf_log_format, blf_data_map) +
|
|
|
|
|
(blfp->blf_map_size * sizeof(blfp->blf_data_map[0]));
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-23 00:52:04 +08:00
|
|
|
static inline bool
|
|
|
|
|
xfs_buf_item_straddle(
|
|
|
|
|
struct xfs_buf *bp,
|
|
|
|
|
uint offset,
|
2021-03-23 00:52:04 +08:00
|
|
|
int first_bit,
|
|
|
|
|
int nbits)
|
2021-03-23 00:52:04 +08:00
|
|
|
{
|
2021-03-23 00:52:04 +08:00
|
|
|
void *first, *last;
|
|
|
|
|
|
|
|
|
|
first = xfs_buf_offset(bp, offset + (first_bit << XFS_BLF_SHIFT));
|
|
|
|
|
last = xfs_buf_offset(bp,
|
|
|
|
|
offset + ((first_bit + nbits) << XFS_BLF_SHIFT));
|
|
|
|
|
|
|
|
|
|
if (last - first != nbits * XFS_BLF_CHUNK)
|
|
|
|
|
return true;
|
|
|
|
|
return false;
|
2021-03-23 00:52:04 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
xfs: Fix CIL throttle hang when CIL space used going backwards
A hang with tasks stuck on the CIL hard throttle was reported and
largely diagnosed by Donald Buczek, who discovered that it was a
result of the CIL context space usage decrementing in committed
transactions once the hard throttle limit had been hit and processes
were already blocked. This resulted in the CIL push not waking up
those waiters because the CIL context was no longer over the hard
throttle limit.
The surprising aspect of this was the CIL space usage going
backwards regularly enough to trigger this situation. Assumptions
had been made in design that the relogging process would only
increase the size of the objects in the CIL, and so that space would
only increase.
This change and commit message fixes the issue and documents the
result of an audit of the triggers that can cause the CIL space to
go backwards, how large the backwards steps tend to be, the
frequency in which they occur, and what the impact on the CIL
accounting code is.
Even though the CIL ctx->space_used can go backwards, it will only
do so if the log item is already logged to the CIL and contains a
space reservation for it's entire logged state. This is tracked by
the shadow buffer state on the log item. If the item is not
previously logged in the CIL it has no shadow buffer nor log vector,
and hence the entire size of the logged item copied to the log
vector is accounted to the CIL space usage. i.e. it will always go
up in this case.
If the item has a log vector (i.e. already in the CIL) and the size
decreases, then the existing log vector will be overwritten and the
space usage will go down. This is the only condition where the space
usage reduces, and it can only occur when an item is already tracked
in the CIL. Hence we are safe from CIL space usage underruns as a
result of log items decreasing in size when they are relogged.
Typically this reduction in CIL usage occurs from metadata blocks
being free, such as when a btree block merge occurs or a directory
enter/xattr entry is removed and the da-tree is reduced in size.
This generally results in a reduction in size of around a single
block in the CIL, but also tends to increase the number of log
vectors because the parent and sibling nodes in the tree needs to be
updated when a btree block is removed. If a multi-level merge
occurs, then we see reduction in size of 2+ blocks, but again the
log vector count goes up.
The other vector is inode fork size changes, which only log the
current size of the fork and ignore the previously logged size when
the fork is relogged. Hence if we are removing items from the inode
fork (dir/xattr removal in shortform, extent record removal in
extent form, etc) the relogged size of the inode for can decrease.
No other log items can decrease in size either because they are a
fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging
an intent actually creates a new intent log item and doesn't relog
the old item at all.) Hence the only two vectors for CIL context
size reduction are relogging inode forks and marking buffers active
in the CIL as stale.
Long story short: the majority of the code does the right thing and
handles the reduction in log item size correctly, and only the CIL
hard throttle implementation is problematic and needs fixing. This
patch makes that fix, as well as adds comments in the log item code
that result in items shrinking in size when they are relogged as a
clear reminder that this can and does happen frequently.
The throttle fix is based upon the change Donald proposed, though it
goes further to ensure that once the throttle is activated, it
captures all tasks until the CIL push issues a wakeup, regardless of
whether the CIL space used has gone back under the throttle
threshold.
This ensures that we prevent tasks reducing the CIL slightly under
the throttle threshold and then making more changes that push it
well over the throttle limit. This is acheived by checking if the
throttle wait queue is already active as a condition of throttling.
Hence once we start throttling, we continue to apply the throttle
until the CIL context push wakes everything on the wait queue.
We can use waitqueue_active() for the waitqueue manipulations and
checks as they are all done under the ctx->xc_push_lock. Hence the
waitqueue has external serialisation and we can safely peek inside
the wait queue without holding the internal waitqueue locks.
Many thanks to Donald for his diagnostic and analysis work to
isolate the cause of this hang.
Reported-and-tested-by: Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-18 23:21:51 +08:00
|
|
|
* Return the number of log iovecs and space needed to log the given buf log
|
|
|
|
|
* item segment.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
xfs: Fix CIL throttle hang when CIL space used going backwards
A hang with tasks stuck on the CIL hard throttle was reported and
largely diagnosed by Donald Buczek, who discovered that it was a
result of the CIL context space usage decrementing in committed
transactions once the hard throttle limit had been hit and processes
were already blocked. This resulted in the CIL push not waking up
those waiters because the CIL context was no longer over the hard
throttle limit.
The surprising aspect of this was the CIL space usage going
backwards regularly enough to trigger this situation. Assumptions
had been made in design that the relogging process would only
increase the size of the objects in the CIL, and so that space would
only increase.
This change and commit message fixes the issue and documents the
result of an audit of the triggers that can cause the CIL space to
go backwards, how large the backwards steps tend to be, the
frequency in which they occur, and what the impact on the CIL
accounting code is.
Even though the CIL ctx->space_used can go backwards, it will only
do so if the log item is already logged to the CIL and contains a
space reservation for it's entire logged state. This is tracked by
the shadow buffer state on the log item. If the item is not
previously logged in the CIL it has no shadow buffer nor log vector,
and hence the entire size of the logged item copied to the log
vector is accounted to the CIL space usage. i.e. it will always go
up in this case.
If the item has a log vector (i.e. already in the CIL) and the size
decreases, then the existing log vector will be overwritten and the
space usage will go down. This is the only condition where the space
usage reduces, and it can only occur when an item is already tracked
in the CIL. Hence we are safe from CIL space usage underruns as a
result of log items decreasing in size when they are relogged.
Typically this reduction in CIL usage occurs from metadata blocks
being free, such as when a btree block merge occurs or a directory
enter/xattr entry is removed and the da-tree is reduced in size.
This generally results in a reduction in size of around a single
block in the CIL, but also tends to increase the number of log
vectors because the parent and sibling nodes in the tree needs to be
updated when a btree block is removed. If a multi-level merge
occurs, then we see reduction in size of 2+ blocks, but again the
log vector count goes up.
The other vector is inode fork size changes, which only log the
current size of the fork and ignore the previously logged size when
the fork is relogged. Hence if we are removing items from the inode
fork (dir/xattr removal in shortform, extent record removal in
extent form, etc) the relogged size of the inode for can decrease.
No other log items can decrease in size either because they are a
fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging
an intent actually creates a new intent log item and doesn't relog
the old item at all.) Hence the only two vectors for CIL context
size reduction are relogging inode forks and marking buffers active
in the CIL as stale.
Long story short: the majority of the code does the right thing and
handles the reduction in log item size correctly, and only the CIL
hard throttle implementation is problematic and needs fixing. This
patch makes that fix, as well as adds comments in the log item code
that result in items shrinking in size when they are relogged as a
clear reminder that this can and does happen frequently.
The throttle fix is based upon the change Donald proposed, though it
goes further to ensure that once the throttle is activated, it
captures all tasks until the CIL push issues a wakeup, regardless of
whether the CIL space used has gone back under the throttle
threshold.
This ensures that we prevent tasks reducing the CIL slightly under
the throttle threshold and then making more changes that push it
well over the throttle limit. This is acheived by checking if the
throttle wait queue is already active as a condition of throttling.
Hence once we start throttling, we continue to apply the throttle
until the CIL context push wakes everything on the wait queue.
We can use waitqueue_active() for the waitqueue manipulations and
checks as they are all done under the ctx->xc_push_lock. Hence the
waitqueue has external serialisation and we can safely peek inside
the wait queue without holding the internal waitqueue locks.
Many thanks to Donald for his diagnostic and analysis work to
isolate the cause of this hang.
Reported-and-tested-by: Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-18 23:21:51 +08:00
|
|
|
* It calculates this as 1 iovec for the buf log format structure and 1 for each
|
|
|
|
|
* stretch of non-contiguous chunks to be logged. Contiguous chunks are logged
|
|
|
|
|
* in a single iovec.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2013-08-12 18:50:04 +08:00
|
|
|
STATIC void
|
2012-06-22 16:50:12 +08:00
|
|
|
xfs_buf_item_size_segment(
|
2018-01-25 05:38:48 +08:00
|
|
|
struct xfs_buf_log_item *bip,
|
|
|
|
|
struct xfs_buf_log_format *blfp,
|
2021-03-23 00:52:04 +08:00
|
|
|
uint offset,
|
2018-01-25 05:38:48 +08:00
|
|
|
int *nvecs,
|
|
|
|
|
int *nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2018-01-25 05:38:48 +08:00
|
|
|
struct xfs_buf *bp = bip->bli_buf;
|
2021-03-23 00:52:04 +08:00
|
|
|
int first_bit;
|
|
|
|
|
int nbits;
|
2018-01-25 05:38:48 +08:00
|
|
|
int next_bit;
|
|
|
|
|
int last_bit;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-03-23 00:52:04 +08:00
|
|
|
first_bit = xfs_next_bit(blfp->blf_data_map, blfp->blf_map_size, 0);
|
|
|
|
|
if (first_bit == -1)
|
2013-08-12 18:50:04 +08:00
|
|
|
return;
|
2012-06-22 16:50:12 +08:00
|
|
|
|
2021-03-23 00:52:04 +08:00
|
|
|
(*nvecs)++;
|
|
|
|
|
*nbytes += xfs_buf_log_format_size(blfp);
|
|
|
|
|
|
|
|
|
|
do {
|
|
|
|
|
nbits = xfs_contig_bits(blfp->blf_data_map,
|
|
|
|
|
blfp->blf_map_size, first_bit);
|
|
|
|
|
ASSERT(nbits > 0);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Straddling a page is rare because we don't log contiguous
|
|
|
|
|
* chunks of unmapped buffers anywhere.
|
|
|
|
|
*/
|
|
|
|
|
if (nbits > 1 &&
|
|
|
|
|
xfs_buf_item_straddle(bp, offset, first_bit, nbits))
|
|
|
|
|
goto slow_scan;
|
|
|
|
|
|
|
|
|
|
(*nvecs)++;
|
|
|
|
|
*nbytes += nbits * XFS_BLF_CHUNK;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This takes the bit number to start looking from and
|
|
|
|
|
* returns the next set bit from there. It returns -1
|
|
|
|
|
* if there are no more bits set or the start bit is
|
|
|
|
|
* beyond the end of the bitmap.
|
|
|
|
|
*/
|
|
|
|
|
first_bit = xfs_next_bit(blfp->blf_data_map, blfp->blf_map_size,
|
|
|
|
|
(uint)first_bit + nbits + 1);
|
|
|
|
|
} while (first_bit != -1);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-03-23 00:52:04 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
slow_scan:
|
|
|
|
|
/* Count the first bit we jumped out of the above loop from */
|
|
|
|
|
(*nvecs)++;
|
|
|
|
|
*nbytes += XFS_BLF_CHUNK;
|
|
|
|
|
last_bit = first_bit;
|
2005-04-17 06:20:36 +08:00
|
|
|
while (last_bit != -1) {
|
|
|
|
|
/*
|
|
|
|
|
* This takes the bit number to start looking from and
|
|
|
|
|
* returns the next set bit from there. It returns -1
|
|
|
|
|
* if there are no more bits set or the start bit is
|
|
|
|
|
* beyond the end of the bitmap.
|
|
|
|
|
*/
|
2012-06-22 16:50:12 +08:00
|
|
|
next_bit = xfs_next_bit(blfp->blf_data_map, blfp->blf_map_size,
|
|
|
|
|
last_bit + 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* If we run out of bits, leave the loop,
|
|
|
|
|
* else if we find a new set of bits bump the number of vecs,
|
|
|
|
|
* else keep scanning the current set of bits.
|
|
|
|
|
*/
|
|
|
|
|
if (next_bit == -1) {
|
2012-06-22 16:50:12 +08:00
|
|
|
break;
|
2021-03-23 00:52:04 +08:00
|
|
|
} else if (next_bit != last_bit + 1 ||
|
2021-03-23 00:52:04 +08:00
|
|
|
xfs_buf_item_straddle(bp, offset, first_bit, nbits)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
last_bit = next_bit;
|
2021-03-23 00:52:04 +08:00
|
|
|
first_bit = next_bit;
|
2013-08-12 18:50:04 +08:00
|
|
|
(*nvecs)++;
|
2021-03-23 00:52:04 +08:00
|
|
|
nbits = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
|
|
|
|
last_bit++;
|
2021-03-23 00:52:04 +08:00
|
|
|
nbits++;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2013-08-12 18:50:04 +08:00
|
|
|
*nbytes += XFS_BLF_CHUNK;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
xfs: Fix CIL throttle hang when CIL space used going backwards
A hang with tasks stuck on the CIL hard throttle was reported and
largely diagnosed by Donald Buczek, who discovered that it was a
result of the CIL context space usage decrementing in committed
transactions once the hard throttle limit had been hit and processes
were already blocked. This resulted in the CIL push not waking up
those waiters because the CIL context was no longer over the hard
throttle limit.
The surprising aspect of this was the CIL space usage going
backwards regularly enough to trigger this situation. Assumptions
had been made in design that the relogging process would only
increase the size of the objects in the CIL, and so that space would
only increase.
This change and commit message fixes the issue and documents the
result of an audit of the triggers that can cause the CIL space to
go backwards, how large the backwards steps tend to be, the
frequency in which they occur, and what the impact on the CIL
accounting code is.
Even though the CIL ctx->space_used can go backwards, it will only
do so if the log item is already logged to the CIL and contains a
space reservation for it's entire logged state. This is tracked by
the shadow buffer state on the log item. If the item is not
previously logged in the CIL it has no shadow buffer nor log vector,
and hence the entire size of the logged item copied to the log
vector is accounted to the CIL space usage. i.e. it will always go
up in this case.
If the item has a log vector (i.e. already in the CIL) and the size
decreases, then the existing log vector will be overwritten and the
space usage will go down. This is the only condition where the space
usage reduces, and it can only occur when an item is already tracked
in the CIL. Hence we are safe from CIL space usage underruns as a
result of log items decreasing in size when they are relogged.
Typically this reduction in CIL usage occurs from metadata blocks
being free, such as when a btree block merge occurs or a directory
enter/xattr entry is removed and the da-tree is reduced in size.
This generally results in a reduction in size of around a single
block in the CIL, but also tends to increase the number of log
vectors because the parent and sibling nodes in the tree needs to be
updated when a btree block is removed. If a multi-level merge
occurs, then we see reduction in size of 2+ blocks, but again the
log vector count goes up.
The other vector is inode fork size changes, which only log the
current size of the fork and ignore the previously logged size when
the fork is relogged. Hence if we are removing items from the inode
fork (dir/xattr removal in shortform, extent record removal in
extent form, etc) the relogged size of the inode for can decrease.
No other log items can decrease in size either because they are a
fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging
an intent actually creates a new intent log item and doesn't relog
the old item at all.) Hence the only two vectors for CIL context
size reduction are relogging inode forks and marking buffers active
in the CIL as stale.
Long story short: the majority of the code does the right thing and
handles the reduction in log item size correctly, and only the CIL
hard throttle implementation is problematic and needs fixing. This
patch makes that fix, as well as adds comments in the log item code
that result in items shrinking in size when they are relogged as a
clear reminder that this can and does happen frequently.
The throttle fix is based upon the change Donald proposed, though it
goes further to ensure that once the throttle is activated, it
captures all tasks until the CIL push issues a wakeup, regardless of
whether the CIL space used has gone back under the throttle
threshold.
This ensures that we prevent tasks reducing the CIL slightly under
the throttle threshold and then making more changes that push it
well over the throttle limit. This is acheived by checking if the
throttle wait queue is already active as a condition of throttling.
Hence once we start throttling, we continue to apply the throttle
until the CIL context push wakes everything on the wait queue.
We can use waitqueue_active() for the waitqueue manipulations and
checks as they are all done under the ctx->xc_push_lock. Hence the
waitqueue has external serialisation and we can safely peek inside
the wait queue without holding the internal waitqueue locks.
Many thanks to Donald for his diagnostic and analysis work to
isolate the cause of this hang.
Reported-and-tested-by: Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-18 23:21:51 +08:00
|
|
|
* Return the number of log iovecs and space needed to log the given buf log
|
|
|
|
|
* item.
|
2012-06-22 16:50:12 +08:00
|
|
|
*
|
2020-08-05 23:49:58 +08:00
|
|
|
* Discontiguous buffers need a format structure per region that is being
|
2012-06-22 16:50:12 +08:00
|
|
|
* logged. This makes the changes in the buffer appear to log recovery as though
|
|
|
|
|
* they came from separate buffers, just like would occur if multiple buffers
|
|
|
|
|
* were used instead of a single discontiguous buffer. This enables
|
|
|
|
|
* discontiguous buffers to be in-memory constructs, completely transparent to
|
|
|
|
|
* what ends up on disk.
|
|
|
|
|
*
|
|
|
|
|
* If the XFS_BLI_STALE flag has been set, then log nothing but the buf log
|
xfs: Fix CIL throttle hang when CIL space used going backwards
A hang with tasks stuck on the CIL hard throttle was reported and
largely diagnosed by Donald Buczek, who discovered that it was a
result of the CIL context space usage decrementing in committed
transactions once the hard throttle limit had been hit and processes
were already blocked. This resulted in the CIL push not waking up
those waiters because the CIL context was no longer over the hard
throttle limit.
The surprising aspect of this was the CIL space usage going
backwards regularly enough to trigger this situation. Assumptions
had been made in design that the relogging process would only
increase the size of the objects in the CIL, and so that space would
only increase.
This change and commit message fixes the issue and documents the
result of an audit of the triggers that can cause the CIL space to
go backwards, how large the backwards steps tend to be, the
frequency in which they occur, and what the impact on the CIL
accounting code is.
Even though the CIL ctx->space_used can go backwards, it will only
do so if the log item is already logged to the CIL and contains a
space reservation for it's entire logged state. This is tracked by
the shadow buffer state on the log item. If the item is not
previously logged in the CIL it has no shadow buffer nor log vector,
and hence the entire size of the logged item copied to the log
vector is accounted to the CIL space usage. i.e. it will always go
up in this case.
If the item has a log vector (i.e. already in the CIL) and the size
decreases, then the existing log vector will be overwritten and the
space usage will go down. This is the only condition where the space
usage reduces, and it can only occur when an item is already tracked
in the CIL. Hence we are safe from CIL space usage underruns as a
result of log items decreasing in size when they are relogged.
Typically this reduction in CIL usage occurs from metadata blocks
being free, such as when a btree block merge occurs or a directory
enter/xattr entry is removed and the da-tree is reduced in size.
This generally results in a reduction in size of around a single
block in the CIL, but also tends to increase the number of log
vectors because the parent and sibling nodes in the tree needs to be
updated when a btree block is removed. If a multi-level merge
occurs, then we see reduction in size of 2+ blocks, but again the
log vector count goes up.
The other vector is inode fork size changes, which only log the
current size of the fork and ignore the previously logged size when
the fork is relogged. Hence if we are removing items from the inode
fork (dir/xattr removal in shortform, extent record removal in
extent form, etc) the relogged size of the inode for can decrease.
No other log items can decrease in size either because they are a
fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging
an intent actually creates a new intent log item and doesn't relog
the old item at all.) Hence the only two vectors for CIL context
size reduction are relogging inode forks and marking buffers active
in the CIL as stale.
Long story short: the majority of the code does the right thing and
handles the reduction in log item size correctly, and only the CIL
hard throttle implementation is problematic and needs fixing. This
patch makes that fix, as well as adds comments in the log item code
that result in items shrinking in size when they are relogged as a
clear reminder that this can and does happen frequently.
The throttle fix is based upon the change Donald proposed, though it
goes further to ensure that once the throttle is activated, it
captures all tasks until the CIL push issues a wakeup, regardless of
whether the CIL space used has gone back under the throttle
threshold.
This ensures that we prevent tasks reducing the CIL slightly under
the throttle threshold and then making more changes that push it
well over the throttle limit. This is acheived by checking if the
throttle wait queue is already active as a condition of throttling.
Hence once we start throttling, we continue to apply the throttle
until the CIL context push wakes everything on the wait queue.
We can use waitqueue_active() for the waitqueue manipulations and
checks as they are all done under the ctx->xc_push_lock. Hence the
waitqueue has external serialisation and we can safely peek inside
the wait queue without holding the internal waitqueue locks.
Many thanks to Donald for his diagnostic and analysis work to
isolate the cause of this hang.
Reported-and-tested-by: Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-18 23:21:51 +08:00
|
|
|
* format structures. If the item has previously been logged and has dirty
|
|
|
|
|
* regions, we do not relog them in stale buffers. This has the effect of
|
|
|
|
|
* reducing the size of the relogged item by the amount of dirty data tracked
|
|
|
|
|
* by the log item. This can result in the committing transaction reducing the
|
|
|
|
|
* amount of space being consumed by the CIL.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2013-08-12 18:50:04 +08:00
|
|
|
STATIC void
|
2012-06-22 16:50:12 +08:00
|
|
|
xfs_buf_item_size(
|
2013-08-12 18:50:04 +08:00
|
|
|
struct xfs_log_item *lip,
|
|
|
|
|
int *nvecs,
|
|
|
|
|
int *nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_buf_log_item *bip = BUF_ITEM(lip);
|
2021-03-23 00:52:04 +08:00
|
|
|
struct xfs_buf *bp = bip->bli_buf;
|
2012-06-22 16:50:12 +08:00
|
|
|
int i;
|
2021-03-23 00:52:03 +08:00
|
|
|
int bytes;
|
2021-03-23 00:52:04 +08:00
|
|
|
uint offset = 0;
|
2012-06-22 16:50:12 +08:00
|
|
|
|
|
|
|
|
ASSERT(atomic_read(&bip->bli_refcount) > 0);
|
|
|
|
|
if (bip->bli_flags & XFS_BLI_STALE) {
|
|
|
|
|
/*
|
xfs: Fix CIL throttle hang when CIL space used going backwards
A hang with tasks stuck on the CIL hard throttle was reported and
largely diagnosed by Donald Buczek, who discovered that it was a
result of the CIL context space usage decrementing in committed
transactions once the hard throttle limit had been hit and processes
were already blocked. This resulted in the CIL push not waking up
those waiters because the CIL context was no longer over the hard
throttle limit.
The surprising aspect of this was the CIL space usage going
backwards regularly enough to trigger this situation. Assumptions
had been made in design that the relogging process would only
increase the size of the objects in the CIL, and so that space would
only increase.
This change and commit message fixes the issue and documents the
result of an audit of the triggers that can cause the CIL space to
go backwards, how large the backwards steps tend to be, the
frequency in which they occur, and what the impact on the CIL
accounting code is.
Even though the CIL ctx->space_used can go backwards, it will only
do so if the log item is already logged to the CIL and contains a
space reservation for it's entire logged state. This is tracked by
the shadow buffer state on the log item. If the item is not
previously logged in the CIL it has no shadow buffer nor log vector,
and hence the entire size of the logged item copied to the log
vector is accounted to the CIL space usage. i.e. it will always go
up in this case.
If the item has a log vector (i.e. already in the CIL) and the size
decreases, then the existing log vector will be overwritten and the
space usage will go down. This is the only condition where the space
usage reduces, and it can only occur when an item is already tracked
in the CIL. Hence we are safe from CIL space usage underruns as a
result of log items decreasing in size when they are relogged.
Typically this reduction in CIL usage occurs from metadata blocks
being free, such as when a btree block merge occurs or a directory
enter/xattr entry is removed and the da-tree is reduced in size.
This generally results in a reduction in size of around a single
block in the CIL, but also tends to increase the number of log
vectors because the parent and sibling nodes in the tree needs to be
updated when a btree block is removed. If a multi-level merge
occurs, then we see reduction in size of 2+ blocks, but again the
log vector count goes up.
The other vector is inode fork size changes, which only log the
current size of the fork and ignore the previously logged size when
the fork is relogged. Hence if we are removing items from the inode
fork (dir/xattr removal in shortform, extent record removal in
extent form, etc) the relogged size of the inode for can decrease.
No other log items can decrease in size either because they are a
fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging
an intent actually creates a new intent log item and doesn't relog
the old item at all.) Hence the only two vectors for CIL context
size reduction are relogging inode forks and marking buffers active
in the CIL as stale.
Long story short: the majority of the code does the right thing and
handles the reduction in log item size correctly, and only the CIL
hard throttle implementation is problematic and needs fixing. This
patch makes that fix, as well as adds comments in the log item code
that result in items shrinking in size when they are relogged as a
clear reminder that this can and does happen frequently.
The throttle fix is based upon the change Donald proposed, though it
goes further to ensure that once the throttle is activated, it
captures all tasks until the CIL push issues a wakeup, regardless of
whether the CIL space used has gone back under the throttle
threshold.
This ensures that we prevent tasks reducing the CIL slightly under
the throttle threshold and then making more changes that push it
well over the throttle limit. This is acheived by checking if the
throttle wait queue is already active as a condition of throttling.
Hence once we start throttling, we continue to apply the throttle
until the CIL context push wakes everything on the wait queue.
We can use waitqueue_active() for the waitqueue manipulations and
checks as they are all done under the ctx->xc_push_lock. Hence the
waitqueue has external serialisation and we can safely peek inside
the wait queue without holding the internal waitqueue locks.
Many thanks to Donald for his diagnostic and analysis work to
isolate the cause of this hang.
Reported-and-tested-by: Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-18 23:21:51 +08:00
|
|
|
* The buffer is stale, so all we need to log is the buf log
|
|
|
|
|
* format structure with the cancel flag in it as we are never
|
|
|
|
|
* going to replay the changes tracked in the log item.
|
2012-06-22 16:50:12 +08:00
|
|
|
*/
|
|
|
|
|
trace_xfs_buf_item_size_stale(bip);
|
2012-12-05 07:18:03 +08:00
|
|
|
ASSERT(bip->__bli_format.blf_flags & XFS_BLF_CANCEL);
|
2013-08-12 18:50:04 +08:00
|
|
|
*nvecs += bip->bli_format_count;
|
|
|
|
|
for (i = 0; i < bip->bli_format_count; i++) {
|
|
|
|
|
*nbytes += xfs_buf_log_format_size(&bip->bli_formats[i]);
|
|
|
|
|
}
|
|
|
|
|
return;
|
2012-06-22 16:50:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ASSERT(bip->bli_flags & XFS_BLI_LOGGED);
|
|
|
|
|
|
2013-06-27 14:04:52 +08:00
|
|
|
if (bip->bli_flags & XFS_BLI_ORDERED) {
|
|
|
|
|
/*
|
xfs: Fix CIL throttle hang when CIL space used going backwards
A hang with tasks stuck on the CIL hard throttle was reported and
largely diagnosed by Donald Buczek, who discovered that it was a
result of the CIL context space usage decrementing in committed
transactions once the hard throttle limit had been hit and processes
were already blocked. This resulted in the CIL push not waking up
those waiters because the CIL context was no longer over the hard
throttle limit.
The surprising aspect of this was the CIL space usage going
backwards regularly enough to trigger this situation. Assumptions
had been made in design that the relogging process would only
increase the size of the objects in the CIL, and so that space would
only increase.
This change and commit message fixes the issue and documents the
result of an audit of the triggers that can cause the CIL space to
go backwards, how large the backwards steps tend to be, the
frequency in which they occur, and what the impact on the CIL
accounting code is.
Even though the CIL ctx->space_used can go backwards, it will only
do so if the log item is already logged to the CIL and contains a
space reservation for it's entire logged state. This is tracked by
the shadow buffer state on the log item. If the item is not
previously logged in the CIL it has no shadow buffer nor log vector,
and hence the entire size of the logged item copied to the log
vector is accounted to the CIL space usage. i.e. it will always go
up in this case.
If the item has a log vector (i.e. already in the CIL) and the size
decreases, then the existing log vector will be overwritten and the
space usage will go down. This is the only condition where the space
usage reduces, and it can only occur when an item is already tracked
in the CIL. Hence we are safe from CIL space usage underruns as a
result of log items decreasing in size when they are relogged.
Typically this reduction in CIL usage occurs from metadata blocks
being free, such as when a btree block merge occurs or a directory
enter/xattr entry is removed and the da-tree is reduced in size.
This generally results in a reduction in size of around a single
block in the CIL, but also tends to increase the number of log
vectors because the parent and sibling nodes in the tree needs to be
updated when a btree block is removed. If a multi-level merge
occurs, then we see reduction in size of 2+ blocks, but again the
log vector count goes up.
The other vector is inode fork size changes, which only log the
current size of the fork and ignore the previously logged size when
the fork is relogged. Hence if we are removing items from the inode
fork (dir/xattr removal in shortform, extent record removal in
extent form, etc) the relogged size of the inode for can decrease.
No other log items can decrease in size either because they are a
fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging
an intent actually creates a new intent log item and doesn't relog
the old item at all.) Hence the only two vectors for CIL context
size reduction are relogging inode forks and marking buffers active
in the CIL as stale.
Long story short: the majority of the code does the right thing and
handles the reduction in log item size correctly, and only the CIL
hard throttle implementation is problematic and needs fixing. This
patch makes that fix, as well as adds comments in the log item code
that result in items shrinking in size when they are relogged as a
clear reminder that this can and does happen frequently.
The throttle fix is based upon the change Donald proposed, though it
goes further to ensure that once the throttle is activated, it
captures all tasks until the CIL push issues a wakeup, regardless of
whether the CIL space used has gone back under the throttle
threshold.
This ensures that we prevent tasks reducing the CIL slightly under
the throttle threshold and then making more changes that push it
well over the throttle limit. This is acheived by checking if the
throttle wait queue is already active as a condition of throttling.
Hence once we start throttling, we continue to apply the throttle
until the CIL context push wakes everything on the wait queue.
We can use waitqueue_active() for the waitqueue manipulations and
checks as they are all done under the ctx->xc_push_lock. Hence the
waitqueue has external serialisation and we can safely peek inside
the wait queue without holding the internal waitqueue locks.
Many thanks to Donald for his diagnostic and analysis work to
isolate the cause of this hang.
Reported-and-tested-by: Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-18 23:21:51 +08:00
|
|
|
* The buffer has been logged just to order it. It is not being
|
|
|
|
|
* included in the transaction commit, so no vectors are used at
|
|
|
|
|
* all.
|
2013-06-27 14:04:52 +08:00
|
|
|
*/
|
|
|
|
|
trace_xfs_buf_item_size_ordered(bip);
|
2013-08-12 18:50:04 +08:00
|
|
|
*nvecs = XFS_LOG_VEC_ORDERED;
|
|
|
|
|
return;
|
2013-06-27 14:04:52 +08:00
|
|
|
}
|
|
|
|
|
|
2012-06-22 16:50:12 +08:00
|
|
|
/*
|
2021-03-23 00:52:03 +08:00
|
|
|
* The vector count is based on the number of buffer vectors we have
|
2012-06-22 16:50:12 +08:00
|
|
|
* dirty bits in. This will only be greater than one when we have a
|
|
|
|
|
* compound buffer with more than one segment dirty. Hence for compound
|
|
|
|
|
* buffers we need to track which segment the dirty bits correspond to,
|
|
|
|
|
* and when we move from one segment to the next increment the vector
|
|
|
|
|
* count for the extra buf log format structure that will need to be
|
|
|
|
|
* written.
|
|
|
|
|
*/
|
2021-03-23 00:52:03 +08:00
|
|
|
bytes = 0;
|
2012-06-22 16:50:12 +08:00
|
|
|
for (i = 0; i < bip->bli_format_count; i++) {
|
2021-03-23 00:52:04 +08:00
|
|
|
xfs_buf_item_size_segment(bip, &bip->bli_formats[i], offset,
|
2021-03-23 00:52:03 +08:00
|
|
|
nvecs, &bytes);
|
2021-03-23 00:52:04 +08:00
|
|
|
offset += BBTOB(bp->b_maps[i].bm_len);
|
2012-06-22 16:50:12 +08:00
|
|
|
}
|
2021-03-23 00:52:03 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Round up the buffer size required to minimise the number of memory
|
|
|
|
|
* allocations that need to be done as this item grows when relogged by
|
|
|
|
|
* repeated modifications.
|
|
|
|
|
*/
|
|
|
|
|
*nbytes = round_up(bytes, 512);
|
2012-06-22 16:50:12 +08:00
|
|
|
trace_xfs_buf_item_size(bip);
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-13 08:00:43 +08:00
|
|
|
static inline void
|
2013-12-13 08:00:43 +08:00
|
|
|
xfs_buf_item_copy_iovec(
|
2013-12-13 08:34:02 +08:00
|
|
|
struct xfs_log_vec *lv,
|
2013-12-13 08:00:43 +08:00
|
|
|
struct xfs_log_iovec **vecp,
|
2013-12-13 08:00:43 +08:00
|
|
|
struct xfs_buf *bp,
|
|
|
|
|
uint offset,
|
|
|
|
|
int first_bit,
|
|
|
|
|
uint nbits)
|
|
|
|
|
{
|
|
|
|
|
offset += first_bit * XFS_BLF_CHUNK;
|
2013-12-13 08:34:02 +08:00
|
|
|
xlog_copy_iovec(lv, vecp, XLOG_REG_TYPE_BCHUNK,
|
2013-12-13 08:00:43 +08:00
|
|
|
xfs_buf_offset(bp, offset),
|
|
|
|
|
nbits * XFS_BLF_CHUNK);
|
2013-12-13 08:00:43 +08:00
|
|
|
}
|
|
|
|
|
|
2013-12-13 08:00:43 +08:00
|
|
|
static void
|
2012-06-22 16:50:12 +08:00
|
|
|
xfs_buf_item_format_segment(
|
|
|
|
|
struct xfs_buf_log_item *bip,
|
2013-12-13 08:34:02 +08:00
|
|
|
struct xfs_log_vec *lv,
|
2013-12-13 08:00:43 +08:00
|
|
|
struct xfs_log_iovec **vecp,
|
2012-06-22 16:50:12 +08:00
|
|
|
uint offset,
|
|
|
|
|
struct xfs_buf_log_format *blfp)
|
|
|
|
|
{
|
2018-01-25 05:38:48 +08:00
|
|
|
struct xfs_buf *bp = bip->bli_buf;
|
|
|
|
|
uint base_size;
|
|
|
|
|
int first_bit;
|
|
|
|
|
int last_bit;
|
|
|
|
|
int next_bit;
|
|
|
|
|
uint nbits;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-06-22 16:50:12 +08:00
|
|
|
/* copy the flags across from the base format item */
|
2012-12-05 07:18:03 +08:00
|
|
|
blfp->blf_flags = bip->__bli_format.blf_flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*
|
2012-06-22 16:50:07 +08:00
|
|
|
* Base size is the actual size of the ondisk structure - it reflects
|
|
|
|
|
* the actual size of the dirty bitmap rather than the size of the in
|
|
|
|
|
* memory structure.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2013-08-12 18:50:04 +08:00
|
|
|
base_size = xfs_buf_log_format_size(blfp);
|
2012-12-05 07:18:04 +08:00
|
|
|
|
|
|
|
|
first_bit = xfs_next_bit(blfp->blf_data_map, blfp->blf_map_size, 0);
|
|
|
|
|
if (!(bip->bli_flags & XFS_BLI_STALE) && first_bit == -1) {
|
|
|
|
|
/*
|
|
|
|
|
* If the map is not be dirty in the transaction, mark
|
|
|
|
|
* the size as zero and do not advance the vector pointer.
|
|
|
|
|
*/
|
2013-12-13 08:34:02 +08:00
|
|
|
return;
|
2012-12-05 07:18:04 +08:00
|
|
|
}
|
|
|
|
|
|
2013-12-13 08:34:02 +08:00
|
|
|
blfp = xlog_copy_iovec(lv, vecp, XLOG_REG_TYPE_BFORMAT, blfp, base_size);
|
|
|
|
|
blfp->blf_size = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
if (bip->bli_flags & XFS_BLI_STALE) {
|
|
|
|
|
/*
|
|
|
|
|
* The buffer is stale, so all we need to log
|
|
|
|
|
* is the buf log format structure with the
|
|
|
|
|
* cancel flag in it.
|
|
|
|
|
*/
|
2009-12-15 07:14:59 +08:00
|
|
|
trace_xfs_buf_item_format_stale(bip);
|
2012-06-22 16:50:12 +08:00
|
|
|
ASSERT(blfp->blf_flags & XFS_BLF_CANCEL);
|
2013-12-13 08:34:02 +08:00
|
|
|
return;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2013-06-27 14:04:52 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* Fill in an iovec for each set of contiguous chunks.
|
|
|
|
|
*/
|
2021-03-23 00:52:04 +08:00
|
|
|
do {
|
|
|
|
|
ASSERT(first_bit >= 0);
|
|
|
|
|
nbits = xfs_contig_bits(blfp->blf_data_map,
|
|
|
|
|
blfp->blf_map_size, first_bit);
|
|
|
|
|
ASSERT(nbits > 0);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Straddling a page is rare because we don't log contiguous
|
|
|
|
|
* chunks of unmapped buffers anywhere.
|
|
|
|
|
*/
|
|
|
|
|
if (nbits > 1 &&
|
|
|
|
|
xfs_buf_item_straddle(bp, offset, first_bit, nbits))
|
|
|
|
|
goto slow_scan;
|
|
|
|
|
|
|
|
|
|
xfs_buf_item_copy_iovec(lv, vecp, bp, offset,
|
|
|
|
|
first_bit, nbits);
|
|
|
|
|
blfp->blf_size++;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This takes the bit number to start looking from and
|
|
|
|
|
* returns the next set bit from there. It returns -1
|
|
|
|
|
* if there are no more bits set or the start bit is
|
|
|
|
|
* beyond the end of the bitmap.
|
|
|
|
|
*/
|
|
|
|
|
first_bit = xfs_next_bit(blfp->blf_data_map, blfp->blf_map_size,
|
|
|
|
|
(uint)first_bit + nbits + 1);
|
|
|
|
|
} while (first_bit != -1);
|
|
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
slow_scan:
|
|
|
|
|
ASSERT(bp->b_addr == NULL);
|
2005-04-17 06:20:36 +08:00
|
|
|
last_bit = first_bit;
|
|
|
|
|
nbits = 1;
|
|
|
|
|
for (;;) {
|
|
|
|
|
/*
|
|
|
|
|
* This takes the bit number to start looking from and
|
|
|
|
|
* returns the next set bit from there. It returns -1
|
|
|
|
|
* if there are no more bits set or the start bit is
|
|
|
|
|
* beyond the end of the bitmap.
|
|
|
|
|
*/
|
2012-06-22 16:50:12 +08:00
|
|
|
next_bit = xfs_next_bit(blfp->blf_data_map, blfp->blf_map_size,
|
|
|
|
|
(uint)last_bit + 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2013-12-13 08:00:43 +08:00
|
|
|
* If we run out of bits fill in the last iovec and get out of
|
|
|
|
|
* the loop. Else if we start a new set of bits then fill in
|
|
|
|
|
* the iovec for the series we were looking at and start
|
|
|
|
|
* counting the bits in the new one. Else we're still in the
|
|
|
|
|
* same set of bits so just keep counting and scanning.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
if (next_bit == -1) {
|
2013-12-13 08:34:02 +08:00
|
|
|
xfs_buf_item_copy_iovec(lv, vecp, bp, offset,
|
2013-12-13 08:00:43 +08:00
|
|
|
first_bit, nbits);
|
2013-12-13 08:34:02 +08:00
|
|
|
blfp->blf_size++;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2013-12-13 08:00:43 +08:00
|
|
|
} else if (next_bit != last_bit + 1 ||
|
2021-03-23 00:52:04 +08:00
|
|
|
xfs_buf_item_straddle(bp, offset, first_bit, nbits)) {
|
2013-12-13 08:34:02 +08:00
|
|
|
xfs_buf_item_copy_iovec(lv, vecp, bp, offset,
|
2013-12-13 08:00:43 +08:00
|
|
|
first_bit, nbits);
|
2013-12-13 08:34:02 +08:00
|
|
|
blfp->blf_size++;
|
2005-04-17 06:20:36 +08:00
|
|
|
first_bit = next_bit;
|
|
|
|
|
last_bit = next_bit;
|
|
|
|
|
nbits = 1;
|
|
|
|
|
} else {
|
|
|
|
|
last_bit++;
|
|
|
|
|
nbits++;
|
|
|
|
|
}
|
|
|
|
|
}
|
2012-06-22 16:50:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This is called to fill in the vector of log iovecs for the
|
|
|
|
|
* given log buf item. It fills the first entry with a buf log
|
|
|
|
|
* format structure, and the rest point to contiguous chunks
|
|
|
|
|
* within the buffer.
|
|
|
|
|
*/
|
|
|
|
|
STATIC void
|
|
|
|
|
xfs_buf_item_format(
|
|
|
|
|
struct xfs_log_item *lip,
|
2013-12-13 08:34:02 +08:00
|
|
|
struct xfs_log_vec *lv)
|
2012-06-22 16:50:12 +08:00
|
|
|
{
|
|
|
|
|
struct xfs_buf_log_item *bip = BUF_ITEM(lip);
|
|
|
|
|
struct xfs_buf *bp = bip->bli_buf;
|
2013-12-13 08:34:02 +08:00
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
2012-06-22 16:50:12 +08:00
|
|
|
uint offset = 0;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
ASSERT(atomic_read(&bip->bli_refcount) > 0);
|
|
|
|
|
ASSERT((bip->bli_flags & XFS_BLI_LOGGED) ||
|
|
|
|
|
(bip->bli_flags & XFS_BLI_STALE));
|
2015-01-22 06:29:05 +08:00
|
|
|
ASSERT((bip->bli_flags & XFS_BLI_STALE) ||
|
|
|
|
|
(xfs_blft_from_flags(&bip->__bli_format) > XFS_BLFT_UNKNOWN_BUF
|
|
|
|
|
&& xfs_blft_from_flags(&bip->__bli_format) < XFS_BLFT_MAX_BUF));
|
2017-08-30 01:08:37 +08:00
|
|
|
ASSERT(!(bip->bli_flags & XFS_BLI_ORDERED) ||
|
|
|
|
|
(bip->bli_flags & XFS_BLI_STALE));
|
2015-01-22 06:29:05 +08:00
|
|
|
|
2012-06-22 16:50:12 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If it is an inode buffer, transfer the in-memory state to the
|
2013-06-27 14:04:56 +08:00
|
|
|
* format flags and clear the in-memory state.
|
|
|
|
|
*
|
|
|
|
|
* For buffer based inode allocation, we do not transfer
|
2012-06-22 16:50:12 +08:00
|
|
|
* this state if the inode buffer allocation has not yet been committed
|
|
|
|
|
* to the log as setting the XFS_BLI_INODE_BUF flag will prevent
|
|
|
|
|
* correct replay of the inode allocation.
|
2013-06-27 14:04:56 +08:00
|
|
|
*
|
|
|
|
|
* For icreate item based inode allocation, the buffers aren't written
|
|
|
|
|
* to the journal during allocation, and hence we should always tag the
|
|
|
|
|
* buffer as an inode buffer so that the correct unlinked list replay
|
|
|
|
|
* occurs during recovery.
|
2012-06-22 16:50:12 +08:00
|
|
|
*/
|
|
|
|
|
if (bip->bli_flags & XFS_BLI_INODE_BUF) {
|
2022-03-18 00:09:12 +08:00
|
|
|
if (xfs_has_v3inodes(lip->li_log->l_mp) ||
|
2013-06-27 14:04:56 +08:00
|
|
|
!((bip->bli_flags & XFS_BLI_INODE_ALLOC_BUF) &&
|
2012-06-22 16:50:12 +08:00
|
|
|
xfs_log_item_in_current_chkpt(lip)))
|
2012-12-05 07:18:03 +08:00
|
|
|
bip->__bli_format.blf_flags |= XFS_BLF_INODE_BUF;
|
2012-06-22 16:50:12 +08:00
|
|
|
bip->bli_flags &= ~XFS_BLI_INODE_BUF;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < bip->bli_format_count; i++) {
|
2013-12-13 08:34:02 +08:00
|
|
|
xfs_buf_item_format_segment(bip, lv, &vecp, offset,
|
2013-12-13 08:00:43 +08:00
|
|
|
&bip->bli_formats[i]);
|
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 15:38:12 +08:00
|
|
|
offset += BBTOB(bp->b_maps[i].bm_len);
|
2012-06-22 16:50:12 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check to make sure everything is consistent.
|
|
|
|
|
*/
|
2009-12-15 07:14:59 +08:00
|
|
|
trace_xfs_buf_item_format(bip);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2010-05-07 09:04:34 +08:00
|
|
|
* This is called to pin the buffer associated with the buf log item in memory
|
2010-06-23 16:11:15 +08:00
|
|
|
* so it cannot be written out.
|
2010-05-07 09:04:34 +08:00
|
|
|
*
|
|
|
|
|
* We also always take a reference to the buffer log item here so that the bli
|
|
|
|
|
* is held while the item is pinned in memory. This means that we can
|
|
|
|
|
* unconditionally drop the reference count a transaction holds when the
|
|
|
|
|
* transaction is completed.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2005-06-21 13:36:52 +08:00
|
|
|
STATIC void
|
2005-04-17 06:20:36 +08:00
|
|
|
xfs_buf_item_pin(
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_log_item *lip)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_buf_log_item *bip = BUF_ITEM(lip);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
ASSERT(atomic_read(&bip->bli_refcount) > 0);
|
|
|
|
|
ASSERT((bip->bli_flags & XFS_BLI_LOGGED) ||
|
2013-06-27 14:04:52 +08:00
|
|
|
(bip->bli_flags & XFS_BLI_ORDERED) ||
|
2005-04-17 06:20:36 +08:00
|
|
|
(bip->bli_flags & XFS_BLI_STALE));
|
2010-06-23 16:11:15 +08:00
|
|
|
|
2009-12-15 07:14:59 +08:00
|
|
|
trace_xfs_buf_item_pin(bip);
|
2010-06-23 16:11:15 +08:00
|
|
|
|
|
|
|
|
atomic_inc(&bip->bli_refcount);
|
|
|
|
|
atomic_inc(&bip->bli_buf->b_pin_count);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
xfs: hold buffer across unpin and potential shutdown processing
The special processing used to simulate a buffer I/O failure on fs
shutdown has a difficult to reproduce race that can result in a use
after free of the associated buffer. Consider a buffer that has been
committed to the on-disk log and thus is AIL resident. The buffer
lands on the writeback delwri queue, but is subsequently locked,
committed and pinned by another transaction before submitted for
I/O. At this point, the buffer is stuck on the delwri queue as it
cannot be submitted for I/O until it is unpinned. A log checkpoint
I/O failure occurs sometime later, which aborts the bli. The unpin
handler is called with the aborted log item, drops the bli reference
count, the pin count, and falls into the I/O failure simulation
path.
The potential problem here is that once the pin count falls to zero
in ->iop_unpin(), xfsaild is free to retry delwri submission of the
buffer at any time, before the unpin handler even completes. If
delwri queue submission wins the race to the buffer lock, it
observes the shutdown state and simulates the I/O failure itself.
This releases both the bli and delwri queue holds and frees the
buffer while xfs_buf_item_unpin() sits on xfs_buf_lock() waiting to
run through the same failure sequence. This problem is rare and
requires many iterations of fstest generic/019 (which simulates disk
I/O failures) to reproduce.
To avoid this problem, grab a hold on the buffer before the log item
is unpinned if the associated item has been aborted and will require
a simulated I/O failure. The hold is already required for the
simulated I/O failure, so the ordering simply guarantees the unpin
handler access to the buffer before it is unpinned and thus
processed by the AIL. This particular ordering is required so long
as the AIL does not acquire a reference on the bli, which is the
long term solution to this problem.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-22 00:43:14 +08:00
|
|
|
* This is called to unpin the buffer associated with the buf log item which
|
|
|
|
|
* was previously pinned with a call to xfs_buf_item_pin().
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2005-06-21 13:36:52 +08:00
|
|
|
STATIC void
|
2005-04-17 06:20:36 +08:00
|
|
|
xfs_buf_item_unpin(
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_log_item *lip,
|
2010-06-23 16:11:15 +08:00
|
|
|
int remove)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_buf_log_item *bip = BUF_ITEM(lip);
|
2020-12-17 08:07:34 +08:00
|
|
|
struct xfs_buf *bp = bip->bli_buf;
|
2018-01-25 05:38:48 +08:00
|
|
|
int stale = bip->bli_flags & XFS_BLI_STALE;
|
|
|
|
|
int freed;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-01-25 05:38:48 +08:00
|
|
|
ASSERT(bp->b_log_item == bip);
|
2005-04-17 06:20:36 +08:00
|
|
|
ASSERT(atomic_read(&bip->bli_refcount) > 0);
|
2010-06-23 16:11:15 +08:00
|
|
|
|
2009-12-15 07:14:59 +08:00
|
|
|
trace_xfs_buf_item_unpin(bip);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
xfs: hold buffer across unpin and potential shutdown processing
The special processing used to simulate a buffer I/O failure on fs
shutdown has a difficult to reproduce race that can result in a use
after free of the associated buffer. Consider a buffer that has been
committed to the on-disk log and thus is AIL resident. The buffer
lands on the writeback delwri queue, but is subsequently locked,
committed and pinned by another transaction before submitted for
I/O. At this point, the buffer is stuck on the delwri queue as it
cannot be submitted for I/O until it is unpinned. A log checkpoint
I/O failure occurs sometime later, which aborts the bli. The unpin
handler is called with the aborted log item, drops the bli reference
count, the pin count, and falls into the I/O failure simulation
path.
The potential problem here is that once the pin count falls to zero
in ->iop_unpin(), xfsaild is free to retry delwri submission of the
buffer at any time, before the unpin handler even completes. If
delwri queue submission wins the race to the buffer lock, it
observes the shutdown state and simulates the I/O failure itself.
This releases both the bli and delwri queue holds and frees the
buffer while xfs_buf_item_unpin() sits on xfs_buf_lock() waiting to
run through the same failure sequence. This problem is rare and
requires many iterations of fstest generic/019 (which simulates disk
I/O failures) to reproduce.
To avoid this problem, grab a hold on the buffer before the log item
is unpinned if the associated item has been aborted and will require
a simulated I/O failure. The hold is already required for the
simulated I/O failure, so the ordering simply guarantees the unpin
handler access to the buffer before it is unpinned and thus
processed by the AIL. This particular ordering is required so long
as the AIL does not acquire a reference on the bli, which is the
long term solution to this problem.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-22 00:43:14 +08:00
|
|
|
/*
|
|
|
|
|
* Drop the bli ref associated with the pin and grab the hold required
|
|
|
|
|
* for the I/O simulation failure in the abort case. We have to do this
|
|
|
|
|
* before the pin count drops because the AIL doesn't acquire a bli
|
|
|
|
|
* reference. Therefore if the refcount drops to zero, the bli could
|
|
|
|
|
* still be AIL resident and the buffer submitted for I/O (and freed on
|
|
|
|
|
* completion) at any point before we return. This can be removed once
|
|
|
|
|
* the AIL properly holds a reference on the bli.
|
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
freed = atomic_dec_and_test(&bip->bli_refcount);
|
xfs: hold buffer across unpin and potential shutdown processing
The special processing used to simulate a buffer I/O failure on fs
shutdown has a difficult to reproduce race that can result in a use
after free of the associated buffer. Consider a buffer that has been
committed to the on-disk log and thus is AIL resident. The buffer
lands on the writeback delwri queue, but is subsequently locked,
committed and pinned by another transaction before submitted for
I/O. At this point, the buffer is stuck on the delwri queue as it
cannot be submitted for I/O until it is unpinned. A log checkpoint
I/O failure occurs sometime later, which aborts the bli. The unpin
handler is called with the aborted log item, drops the bli reference
count, the pin count, and falls into the I/O failure simulation
path.
The potential problem here is that once the pin count falls to zero
in ->iop_unpin(), xfsaild is free to retry delwri submission of the
buffer at any time, before the unpin handler even completes. If
delwri queue submission wins the race to the buffer lock, it
observes the shutdown state and simulates the I/O failure itself.
This releases both the bli and delwri queue holds and frees the
buffer while xfs_buf_item_unpin() sits on xfs_buf_lock() waiting to
run through the same failure sequence. This problem is rare and
requires many iterations of fstest generic/019 (which simulates disk
I/O failures) to reproduce.
To avoid this problem, grab a hold on the buffer before the log item
is unpinned if the associated item has been aborted and will require
a simulated I/O failure. The hold is already required for the
simulated I/O failure, so the ordering simply guarantees the unpin
handler access to the buffer before it is unpinned and thus
processed by the AIL. This particular ordering is required so long
as the AIL does not acquire a reference on the bli, which is the
long term solution to this problem.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-22 00:43:14 +08:00
|
|
|
if (freed && !stale && remove)
|
|
|
|
|
xfs_buf_hold(bp);
|
2010-06-23 16:11:15 +08:00
|
|
|
if (atomic_dec_and_test(&bp->b_pin_count))
|
|
|
|
|
wake_up_all(&bp->b_waiters);
|
2010-06-23 16:11:15 +08:00
|
|
|
|
xfs: hold buffer across unpin and potential shutdown processing
The special processing used to simulate a buffer I/O failure on fs
shutdown has a difficult to reproduce race that can result in a use
after free of the associated buffer. Consider a buffer that has been
committed to the on-disk log and thus is AIL resident. The buffer
lands on the writeback delwri queue, but is subsequently locked,
committed and pinned by another transaction before submitted for
I/O. At this point, the buffer is stuck on the delwri queue as it
cannot be submitted for I/O until it is unpinned. A log checkpoint
I/O failure occurs sometime later, which aborts the bli. The unpin
handler is called with the aborted log item, drops the bli reference
count, the pin count, and falls into the I/O failure simulation
path.
The potential problem here is that once the pin count falls to zero
in ->iop_unpin(), xfsaild is free to retry delwri submission of the
buffer at any time, before the unpin handler even completes. If
delwri queue submission wins the race to the buffer lock, it
observes the shutdown state and simulates the I/O failure itself.
This releases both the bli and delwri queue holds and frees the
buffer while xfs_buf_item_unpin() sits on xfs_buf_lock() waiting to
run through the same failure sequence. This problem is rare and
requires many iterations of fstest generic/019 (which simulates disk
I/O failures) to reproduce.
To avoid this problem, grab a hold on the buffer before the log item
is unpinned if the associated item has been aborted and will require
a simulated I/O failure. The hold is already required for the
simulated I/O failure, so the ordering simply guarantees the unpin
handler access to the buffer before it is unpinned and thus
processed by the AIL. This particular ordering is required so long
as the AIL does not acquire a reference on the bli, which is the
long term solution to this problem.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-22 00:43:14 +08:00
|
|
|
/* nothing to do but drop the pin count if the bli is active */
|
|
|
|
|
if (!freed)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (stale) {
|
2005-04-17 06:20:36 +08:00
|
|
|
ASSERT(bip->bli_flags & XFS_BLI_STALE);
|
2011-07-08 20:36:19 +08:00
|
|
|
ASSERT(xfs_buf_islocked(bp));
|
2016-02-10 12:01:11 +08:00
|
|
|
ASSERT(bp->b_flags & XBF_STALE);
|
2012-12-05 07:18:03 +08:00
|
|
|
ASSERT(bip->__bli_format.blf_flags & XFS_BLF_CANCEL);
|
2021-06-22 00:43:14 +08:00
|
|
|
ASSERT(list_empty(&lip->li_trans));
|
|
|
|
|
ASSERT(!bp->b_transp);
|
2010-06-23 16:11:15 +08:00
|
|
|
|
2009-12-15 07:14:59 +08:00
|
|
|
trace_xfs_buf_item_unpin_stale(bip);
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2020-05-07 04:25:23 +08:00
|
|
|
* If we get called here because of an IO error, we may or may
|
|
|
|
|
* not have the item on the AIL. xfs_trans_ail_delete() will
|
|
|
|
|
* take care of that situation. xfs_trans_ail_delete() drops
|
|
|
|
|
* the AIL lock.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
if (bip->bli_flags & XFS_BLI_STALE_INODE) {
|
2020-06-30 05:49:14 +08:00
|
|
|
xfs_buf_item_done(bp);
|
2020-09-02 01:55:29 +08:00
|
|
|
xfs_buf_inode_iodone(bp);
|
2020-06-30 05:49:18 +08:00
|
|
|
ASSERT(list_empty(&bp->b_li_list));
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2020-05-07 04:25:23 +08:00
|
|
|
xfs_trans_ail_delete(lip, SHUTDOWN_LOG_IO_ERROR);
|
2005-04-17 06:20:36 +08:00
|
|
|
xfs_buf_item_relse(bp);
|
2018-01-25 05:38:48 +08:00
|
|
|
ASSERT(bp->b_log_item == NULL);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
xfs_buf_relse(bp);
|
xfs: hold buffer across unpin and potential shutdown processing
The special processing used to simulate a buffer I/O failure on fs
shutdown has a difficult to reproduce race that can result in a use
after free of the associated buffer. Consider a buffer that has been
committed to the on-disk log and thus is AIL resident. The buffer
lands on the writeback delwri queue, but is subsequently locked,
committed and pinned by another transaction before submitted for
I/O. At this point, the buffer is stuck on the delwri queue as it
cannot be submitted for I/O until it is unpinned. A log checkpoint
I/O failure occurs sometime later, which aborts the bli. The unpin
handler is called with the aborted log item, drops the bli reference
count, the pin count, and falls into the I/O failure simulation
path.
The potential problem here is that once the pin count falls to zero
in ->iop_unpin(), xfsaild is free to retry delwri submission of the
buffer at any time, before the unpin handler even completes. If
delwri queue submission wins the race to the buffer lock, it
observes the shutdown state and simulates the I/O failure itself.
This releases both the bli and delwri queue holds and frees the
buffer while xfs_buf_item_unpin() sits on xfs_buf_lock() waiting to
run through the same failure sequence. This problem is rare and
requires many iterations of fstest generic/019 (which simulates disk
I/O failures) to reproduce.
To avoid this problem, grab a hold on the buffer before the log item
is unpinned if the associated item has been aborted and will require
a simulated I/O failure. The hold is already required for the
simulated I/O failure, so the ordering simply guarantees the unpin
handler access to the buffer before it is unpinned and thus
processed by the AIL. This particular ordering is required so long
as the AIL does not acquire a reference on the bli, which is the
long term solution to this problem.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-22 00:43:14 +08:00
|
|
|
} else if (remove) {
|
2012-11-02 11:23:12 +08:00
|
|
|
/*
|
2020-05-07 04:25:19 +08:00
|
|
|
* The buffer must be locked and held by the caller to simulate
|
xfs: hold buffer across unpin and potential shutdown processing
The special processing used to simulate a buffer I/O failure on fs
shutdown has a difficult to reproduce race that can result in a use
after free of the associated buffer. Consider a buffer that has been
committed to the on-disk log and thus is AIL resident. The buffer
lands on the writeback delwri queue, but is subsequently locked,
committed and pinned by another transaction before submitted for
I/O. At this point, the buffer is stuck on the delwri queue as it
cannot be submitted for I/O until it is unpinned. A log checkpoint
I/O failure occurs sometime later, which aborts the bli. The unpin
handler is called with the aborted log item, drops the bli reference
count, the pin count, and falls into the I/O failure simulation
path.
The potential problem here is that once the pin count falls to zero
in ->iop_unpin(), xfsaild is free to retry delwri submission of the
buffer at any time, before the unpin handler even completes. If
delwri queue submission wins the race to the buffer lock, it
observes the shutdown state and simulates the I/O failure itself.
This releases both the bli and delwri queue holds and frees the
buffer while xfs_buf_item_unpin() sits on xfs_buf_lock() waiting to
run through the same failure sequence. This problem is rare and
requires many iterations of fstest generic/019 (which simulates disk
I/O failures) to reproduce.
To avoid this problem, grab a hold on the buffer before the log item
is unpinned if the associated item has been aborted and will require
a simulated I/O failure. The hold is already required for the
simulated I/O failure, so the ordering simply guarantees the unpin
handler access to the buffer before it is unpinned and thus
processed by the AIL. This particular ordering is required so long
as the AIL does not acquire a reference on the bli, which is the
long term solution to this problem.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-06-22 00:43:14 +08:00
|
|
|
* an async I/O failure. We acquired the hold for this case
|
|
|
|
|
* before the buffer was unpinned.
|
2012-11-02 11:23:12 +08:00
|
|
|
*/
|
2012-04-23 13:58:38 +08:00
|
|
|
xfs_buf_lock(bp);
|
2012-11-02 11:23:12 +08:00
|
|
|
bp->b_flags |= XBF_ASYNC;
|
2020-05-07 04:25:19 +08:00
|
|
|
xfs_buf_ioend_fail(bp);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-06-21 13:36:52 +08:00
|
|
|
STATIC uint
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
xfs_buf_item_push(
|
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
|
struct list_head *buffer_list)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_buf_log_item *bip = BUF_ITEM(lip);
|
|
|
|
|
struct xfs_buf *bp = bip->bli_buf;
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
uint rval = XFS_ITEM_SUCCESS;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-07-23 07:40:27 +08:00
|
|
|
if (xfs_buf_ispinned(bp))
|
2005-04-17 06:20:36 +08:00
|
|
|
return XFS_ITEM_PINNED;
|
2013-02-11 23:08:21 +08:00
|
|
|
if (!xfs_buf_trylock(bp)) {
|
|
|
|
|
/*
|
|
|
|
|
* If we have just raced with a buffer being pinned and it has
|
|
|
|
|
* been marked stale, we could end up stalling until someone else
|
|
|
|
|
* issues a log force to unpin the stale buffer. Check for the
|
|
|
|
|
* race condition here so xfsaild recognizes the buffer is pinned
|
|
|
|
|
* and queues a log force to move it along.
|
|
|
|
|
*/
|
|
|
|
|
if (xfs_buf_ispinned(bp))
|
|
|
|
|
return XFS_ITEM_PINNED;
|
2005-04-17 06:20:36 +08:00
|
|
|
return XFS_ITEM_LOCKED;
|
2013-02-11 23:08:21 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
ASSERT(!(bip->bli_flags & XFS_BLI_STALE));
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
|
|
|
|
|
trace_xfs_buf_item_push(bip);
|
|
|
|
|
|
xfs: abort metadata writeback on permanent errors
If we are doing aysnc writeback of metadata, we can get write errors
but have nobody to report them to. At the moment, we simply attempt
to reissue the write from io completion in the hope that it's a
transient error.
When it's not a transient error, the buffer is stuck forever in
this loop, and we cannot break out of it. Eventually, unmount will
hang because the AIL cannot be emptied and everything goes downhill
from them.
To solve this problem, only retry the write IO once before aborting
it. We don't throw the buffer away because some transient errors can
last minutes (e.g. FC path failover) or even hours (thin
provisioned devices that have run out of backing space) before they
go away. Hence we really want to keep trying until we can't try any
more.
Because the buffer was not cleaned, however, it does not get removed
from the AIL and hence the next pass across the AIL will start IO on
it again. As such, we still get the "retry forever" semantics that
we currently have, but we allow other access to the buffer in the
mean time. Meanwhile the filesystem can continue to modify the
buffer and relog it, so the IO errors won't hang the log or the
filesystem.
Now when we are pushing the AIL, we can see all these "permanent IO
error" buffers and we can issue a warning about failures before we
retry the IO. We can also catch these buffers when unmounting an
issue a corruption warning, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-12-12 13:34:38 +08:00
|
|
|
/* has a previous flush failed due to IO errors? */
|
2020-05-07 04:25:21 +08:00
|
|
|
if (bp->b_flags & XBF_WRITE_FAIL) {
|
|
|
|
|
xfs_buf_alert_ratelimited(bp, "XFS: Failing async write",
|
|
|
|
|
"Failing async write on buffer block 0x%llx. Retrying async write.",
|
2021-08-19 09:47:05 +08:00
|
|
|
(long long)xfs_buf_daddr(bp));
|
xfs: abort metadata writeback on permanent errors
If we are doing aysnc writeback of metadata, we can get write errors
but have nobody to report them to. At the moment, we simply attempt
to reissue the write from io completion in the hope that it's a
transient error.
When it's not a transient error, the buffer is stuck forever in
this loop, and we cannot break out of it. Eventually, unmount will
hang because the AIL cannot be emptied and everything goes downhill
from them.
To solve this problem, only retry the write IO once before aborting
it. We don't throw the buffer away because some transient errors can
last minutes (e.g. FC path failover) or even hours (thin
provisioned devices that have run out of backing space) before they
go away. Hence we really want to keep trying until we can't try any
more.
Because the buffer was not cleaned, however, it does not get removed
from the AIL and hence the next pass across the AIL will start IO on
it again. As such, we still get the "retry forever" semantics that
we currently have, but we allow other access to the buffer in the
mean time. Meanwhile the filesystem can continue to modify the
buffer and relog it, so the IO errors won't hang the log or the
filesystem.
Now when we are pushing the AIL, we can see all these "permanent IO
error" buffers and we can issue a warning about failures before we
retry the IO. We can also catch these buffers when unmounting an
issue a corruption warning, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
2013-12-12 13:34:38 +08:00
|
|
|
}
|
|
|
|
|
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 13:58:39 +08:00
|
|
|
if (!xfs_buf_delwri_queue(bp, buffer_list))
|
|
|
|
|
rval = XFS_ITEM_FLUSHING;
|
|
|
|
|
xfs_buf_unlock(bp);
|
|
|
|
|
return rval;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:45:26 +08:00
|
|
|
/*
|
|
|
|
|
* Drop the buffer log item refcount and take appropriate action. This helper
|
|
|
|
|
* determines whether the bli must be freed or not, since a decrement to zero
|
|
|
|
|
* does not necessarily mean the bli is unused.
|
|
|
|
|
*
|
|
|
|
|
* Return true if the bli is freed, false otherwise.
|
|
|
|
|
*/
|
|
|
|
|
bool
|
|
|
|
|
xfs_buf_item_put(
|
|
|
|
|
struct xfs_buf_log_item *bip)
|
|
|
|
|
{
|
|
|
|
|
struct xfs_log_item *lip = &bip->bli_item;
|
|
|
|
|
bool aborted;
|
|
|
|
|
bool dirty;
|
|
|
|
|
|
|
|
|
|
/* drop the bli ref and return if it wasn't the last one */
|
|
|
|
|
if (!atomic_dec_and_test(&bip->bli_refcount))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We dropped the last ref and must free the item if clean or aborted.
|
|
|
|
|
* If the bli is dirty and non-aborted, the buffer was clean in the
|
|
|
|
|
* transaction but still awaiting writeback from previous changes. In
|
|
|
|
|
* that case, the bli is freed on buffer writeback completion.
|
|
|
|
|
*/
|
|
|
|
|
aborted = test_bit(XFS_LI_ABORTED, &lip->li_flags) ||
|
2022-03-18 00:09:12 +08:00
|
|
|
xlog_is_shutdown(lip->li_log);
|
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:45:26 +08:00
|
|
|
dirty = bip->bli_flags & XFS_BLI_DIRTY;
|
|
|
|
|
if (dirty && !aborted)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The bli is aborted or clean. An aborted item may be in the AIL
|
|
|
|
|
* regardless of dirty state. For example, consider an aborted
|
|
|
|
|
* transaction that invalidated a dirty bli and cleared the dirty
|
|
|
|
|
* state.
|
|
|
|
|
*/
|
|
|
|
|
if (aborted)
|
2020-05-07 04:27:04 +08:00
|
|
|
xfs_trans_ail_delete(lip, 0);
|
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:45:26 +08:00
|
|
|
xfs_buf_item_relse(bip->bli_buf);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2010-05-07 09:04:34 +08:00
|
|
|
* Release the buffer associated with the buf log item. If there is no dirty
|
|
|
|
|
* logged data associated with the buffer recorded in the buf log item, then
|
|
|
|
|
* free the buf log item and remove the reference to it in the buffer.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2010-05-07 09:04:34 +08:00
|
|
|
* This call ignores the recursion count. It is only called when the buffer
|
|
|
|
|
* should REALLY be unlocked, regardless of the recursion count.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2010-05-07 09:04:34 +08:00
|
|
|
* We unconditionally drop the transaction's reference to the log item. If the
|
|
|
|
|
* item was logged, then another reference was taken when it was pinned, so we
|
|
|
|
|
* can safely drop the transaction reference now. This also allows us to avoid
|
|
|
|
|
* potential races with the unpin code freeing the bli by not referencing the
|
|
|
|
|
* bli after we've dropped the reference count.
|
|
|
|
|
*
|
|
|
|
|
* If the XFS_BLI_HOLD flag is set in the buf log item, then free the log item
|
|
|
|
|
* if necessary but do not unlock the buffer. This is for support of
|
|
|
|
|
* xfs_trans_bhold(). Make sure the XFS_BLI_HOLD field is cleared if we don't
|
|
|
|
|
* free the item.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2005-06-21 13:36:52 +08:00
|
|
|
STATIC void
|
2019-06-29 10:27:32 +08:00
|
|
|
xfs_buf_item_release(
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_log_item *lip)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_buf_log_item *bip = BUF_ITEM(lip);
|
|
|
|
|
struct xfs_buf *bp = bip->bli_buf;
|
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:45:26 +08:00
|
|
|
bool released;
|
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:44:40 +08:00
|
|
|
bool hold = bip->bli_flags & XFS_BLI_HOLD;
|
|
|
|
|
bool stale = bip->bli_flags & XFS_BLI_STALE;
|
2017-09-01 06:11:06 +08:00
|
|
|
#if defined(DEBUG) || defined(XFS_WARN)
|
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:44:40 +08:00
|
|
|
bool ordered = bip->bli_flags & XFS_BLI_ORDERED;
|
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:45:26 +08:00
|
|
|
bool dirty = bip->bli_flags & XFS_BLI_DIRTY;
|
2019-04-12 22:39:19 +08:00
|
|
|
bool aborted = test_bit(XFS_LI_ABORTED,
|
|
|
|
|
&lip->li_flags);
|
2017-09-01 06:11:06 +08:00
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2019-06-29 10:27:32 +08:00
|
|
|
trace_xfs_buf_item_release(bip);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*
|
2017-08-30 01:08:37 +08:00
|
|
|
* The bli dirty state should match whether the blf has logged segments
|
|
|
|
|
* except for ordered buffers, where only the bli should be dirty.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2017-08-30 01:08:37 +08:00
|
|
|
ASSERT((!ordered && dirty == xfs_buf_item_dirty_format(bip)) ||
|
|
|
|
|
(ordered && dirty && !xfs_buf_item_dirty_format(bip)));
|
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:44:40 +08:00
|
|
|
ASSERT(!stale || (bip->__bli_format.blf_flags & XFS_BLF_CANCEL));
|
|
|
|
|
|
2013-09-03 19:47:37 +08:00
|
|
|
/*
|
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:44:40 +08:00
|
|
|
* Clear the buffer's association with this transaction and
|
|
|
|
|
* per-transaction state from the bli, which has been copied above.
|
|
|
|
|
*/
|
|
|
|
|
bp->b_transp = NULL;
|
|
|
|
|
bip->bli_flags &= ~(XFS_BLI_LOGGED | XFS_BLI_HOLD | XFS_BLI_ORDERED);
|
|
|
|
|
|
|
|
|
|
/*
|
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:45:26 +08:00
|
|
|
* Unref the item and unlock the buffer unless held or stale. Stale
|
|
|
|
|
* buffers remain locked until final unpin unless the bli is freed by
|
|
|
|
|
* the unref call. The latter implies shutdown because buffer
|
|
|
|
|
* invalidation dirties the bli and transaction.
|
2013-09-03 19:47:37 +08:00
|
|
|
*/
|
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:45:26 +08:00
|
|
|
released = xfs_buf_item_put(bip);
|
|
|
|
|
if (hold || (stale && !released))
|
xfs: don't unlock invalidated buf on aborted tx commit
xfstests generic/388,475 occasionally reproduce assertion failures
in xfs_buf_item_unpin() when the final bli reference is dropped on
an invalidated buffer and the buffer is not locked as it is expected
to be. Invalidated buffers should remain locked on transaction
commit until the final unpin, at which point the buffer is removed
from the AIL and the bli is freed since stale buffers are not
written back.
The assert failures are associated with filesystem shutdown,
typically due to log I/O errors injected by the test. The
problematic situation can occur if the shutdown happens to cause a
race between an active transaction that has invalidated a particular
buffer and an I/O error on a log buffer that contains the bli
associated with the same (now stale) buffer.
Both transaction and log contexts acquire a bli reference. If the
transaction has already invalidated the buffer by the time the I/O
error occurs and ends up aborting due to shutdown, the transaction
and log hold the last two references to a stale bli. If the
transaction cancel occurs first, it treats the buffer as non-stale
due to the aborted state: the bli reference is dropped and the
buffer is released/unlocked. The log buffer I/O error handling
eventually calls into xfs_buf_item_unpin(), drops the final
reference to the bli and treats it as stale. The buffer wasn't left
locked by xfs_buf_item_unlock(), however, so the assert fails and
the buffer is double unlocked. The latter problem is mitigated by
the fact that the fs is shutdown and no further damage is possible.
->iop_unlock() of an invalidated buffer should behave consistently
with respect to the bli refcount, regardless of aborted state. If
the refcount remains elevated on commit, we know the bli is awaiting
an unpin (since it can't be in another transaction) and will be
handled appropriately on log buffer completion. If the final bli
reference of an invalidated buffer is dropped in ->iop_unlock(), we
can assume the transaction has aborted because invalidation implies
a dirty transaction. In the non-abort case, the log would have
acquired a bli reference in ->iop_pin() and prevented bli release at
->iop_unlock() time. In the abort case the item must be freed and
buffer unlocked because it wasn't pinned by the log.
Rework xfs_buf_item_unlock() to simplify the currently circuitous
and duplicate logic and leave invalidated buffers locked based on
bli refcount, regardless of aborted state. This ensures that a
pinned, stale buffer is always found locked when eventually
unpinned.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:44:40 +08:00
|
|
|
return;
|
2019-04-12 22:39:19 +08:00
|
|
|
ASSERT(!stale || aborted);
|
xfs: refactor xfs_buf_log_item reference count handling
The xfs_buf_log_item structure has a reference counter with slightly
tricky semantics. In the common case, a buffer is logged and
committed in a transaction, committed to the on-disk log (added to
the AIL) and then finally written back and removed from the AIL. The
bli refcount covers two potentially overlapping timeframes:
1. the bli is held in an active transaction
2. the bli is pinned by the log
The caveat to this approach is that the reference counter does not
purely dictate the lifetime of the bli. IOW, when a dirty buffer is
physically logged and unpinned, the bli refcount may go to zero as
the log item is inserted into the AIL. Only once the buffer is
written back can the bli finally be freed.
The above semantics means that it is not enough for the various
refcount decrementing contexts to release the bli on decrement to
zero. xfs_trans_brelse(), transaction commit (->iop_unlock()) and
unpin (->iop_unpin()) must all drop the associated reference and
make additional checks to determine if the current context is
responsible for freeing the item.
For example, if a transaction holds but does not dirty a particular
bli, the commit may drop the refcount to zero. If the bli itself is
clean, it is also not AIL resident and must be freed at this time.
The same is true for xfs_trans_brelse(). If the transaction dirties
a bli and then aborts or an unpin results in an abort due to a log
I/O error, the last reference count holder is expected to explicitly
remove the item from the AIL and release it (since an abort means
filesystem shutdown and metadata writeback will never occur).
This leads to fairly complex checks being replicated in a few
different places. Since ->iop_unlock() and xfs_trans_brelse() are
nearly identical, refactor the logic into a common helper that
implements and documents the semantics in one place. This patch does
not change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-09-29 11:45:26 +08:00
|
|
|
xfs_buf_relse(bp);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2019-06-29 10:27:32 +08:00
|
|
|
STATIC void
|
|
|
|
|
xfs_buf_item_committing(
|
|
|
|
|
struct xfs_log_item *lip,
|
2021-06-18 23:21:52 +08:00
|
|
|
xfs_csn_t seq)
|
2019-06-29 10:27:32 +08:00
|
|
|
{
|
|
|
|
|
return xfs_buf_item_release(lip);
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* This is called to find out where the oldest active copy of the
|
|
|
|
|
* buf log item in the on disk log resides now that the last log
|
|
|
|
|
* write of it completed at the given lsn.
|
|
|
|
|
* We always re-log all the dirty data in a buffer, so usually the
|
|
|
|
|
* latest copy in the on disk log is the only one that matters. For
|
|
|
|
|
* those cases we simply return the given lsn.
|
|
|
|
|
*
|
|
|
|
|
* The one exception to this is for buffers full of newly allocated
|
|
|
|
|
* inodes. These buffers are only relogged with the XFS_BLI_INODE_BUF
|
|
|
|
|
* flag set, indicating that only the di_next_unlinked fields from the
|
|
|
|
|
* inodes in the buffers will be replayed during recovery. If the
|
|
|
|
|
* original newly allocated inode images have not yet been flushed
|
|
|
|
|
* when the buffer is so relogged, then we need to make sure that we
|
|
|
|
|
* keep the old images in the 'active' portion of the log. We do this
|
|
|
|
|
* by returning the original lsn of that transaction here rather than
|
|
|
|
|
* the current one.
|
|
|
|
|
*/
|
2005-06-21 13:36:52 +08:00
|
|
|
STATIC xfs_lsn_t
|
2005-04-17 06:20:36 +08:00
|
|
|
xfs_buf_item_committed(
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_log_item *lip,
|
2005-04-17 06:20:36 +08:00
|
|
|
xfs_lsn_t lsn)
|
|
|
|
|
{
|
2010-06-23 16:11:15 +08:00
|
|
|
struct xfs_buf_log_item *bip = BUF_ITEM(lip);
|
|
|
|
|
|
2009-12-15 07:14:59 +08:00
|
|
|
trace_xfs_buf_item_committed(bip);
|
|
|
|
|
|
2010-06-23 16:11:15 +08:00
|
|
|
if ((bip->bli_flags & XFS_BLI_INODE_ALLOC_BUF) && lip->li_lsn != 0)
|
|
|
|
|
return lip->li_lsn;
|
|
|
|
|
return lsn;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2011-10-28 17:54:24 +08:00
|
|
|
static const struct xfs_item_ops xfs_buf_item_ops = {
|
2010-06-23 16:11:15 +08:00
|
|
|
.iop_size = xfs_buf_item_size,
|
|
|
|
|
.iop_format = xfs_buf_item_format,
|
|
|
|
|
.iop_pin = xfs_buf_item_pin,
|
|
|
|
|
.iop_unpin = xfs_buf_item_unpin,
|
2019-06-29 10:27:32 +08:00
|
|
|
.iop_release = xfs_buf_item_release,
|
|
|
|
|
.iop_committing = xfs_buf_item_committing,
|
2010-06-23 16:11:15 +08:00
|
|
|
.iop_committed = xfs_buf_item_committed,
|
|
|
|
|
.iop_push = xfs_buf_item_push,
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
2020-01-09 01:21:22 +08:00
|
|
|
STATIC void
|
2012-06-22 16:50:12 +08:00
|
|
|
xfs_buf_item_get_format(
|
|
|
|
|
struct xfs_buf_log_item *bip,
|
|
|
|
|
int count)
|
|
|
|
|
{
|
|
|
|
|
ASSERT(bip->bli_formats == NULL);
|
|
|
|
|
bip->bli_format_count = count;
|
|
|
|
|
|
|
|
|
|
if (count == 1) {
|
2012-12-05 07:18:03 +08:00
|
|
|
bip->bli_formats = &bip->__bli_format;
|
2020-01-09 01:21:22 +08:00
|
|
|
return;
|
2012-06-22 16:50:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bip->bli_formats = kmem_zalloc(count * sizeof(struct xfs_buf_log_format),
|
2019-08-27 03:06:22 +08:00
|
|
|
0);
|
2012-06-22 16:50:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
STATIC void
|
|
|
|
|
xfs_buf_item_free_format(
|
|
|
|
|
struct xfs_buf_log_item *bip)
|
|
|
|
|
{
|
2012-12-05 07:18:03 +08:00
|
|
|
if (bip->bli_formats != &bip->__bli_format) {
|
2012-06-22 16:50:12 +08:00
|
|
|
kmem_free(bip->bli_formats);
|
|
|
|
|
bip->bli_formats = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allocate a new buf log item to go with the given buffer.
|
2018-01-25 05:38:48 +08:00
|
|
|
* Set the buffer's b_log_item field to point to the new
|
|
|
|
|
* buf log item.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2015-08-25 08:05:13 +08:00
|
|
|
int
|
2005-04-17 06:20:36 +08:00
|
|
|
xfs_buf_item_init(
|
2015-08-25 08:05:13 +08:00
|
|
|
struct xfs_buf *bp,
|
|
|
|
|
struct xfs_mount *mp)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2018-01-25 05:38:48 +08:00
|
|
|
struct xfs_buf_log_item *bip = bp->b_log_item;
|
2005-04-17 06:20:36 +08:00
|
|
|
int chunks;
|
|
|
|
|
int map_size;
|
2012-06-22 16:50:12 +08:00
|
|
|
int i;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check to see if there is already a buf log item for
|
2018-01-25 05:38:48 +08:00
|
|
|
* this buffer. If we do already have one, there is
|
2005-04-17 06:20:36 +08:00
|
|
|
* nothing to do here so return.
|
|
|
|
|
*/
|
2019-06-29 10:27:29 +08:00
|
|
|
ASSERT(bp->b_mount == mp);
|
2018-05-09 22:49:10 +08:00
|
|
|
if (bip) {
|
2018-01-25 05:38:48 +08:00
|
|
|
ASSERT(bip->bli_item.li_type == XFS_LI_BUF);
|
2018-05-09 22:49:10 +08:00
|
|
|
ASSERT(!bp->b_transp);
|
|
|
|
|
ASSERT(bip->bli_buf == bp);
|
2015-08-25 08:05:13 +08:00
|
|
|
return 0;
|
2018-01-25 05:38:48 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-10-13 02:09:23 +08:00
|
|
|
bip = kmem_cache_zalloc(xfs_buf_item_cache, GFP_KERNEL | __GFP_NOFAIL);
|
2010-03-23 07:10:00 +08:00
|
|
|
xfs_log_item_init(mp, &bip->bli_item, XFS_LI_BUF, &xfs_buf_item_ops);
|
2005-04-17 06:20:36 +08:00
|
|
|
bip->bli_buf = bp;
|
2012-06-22 16:50:12 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* chunks is the number of XFS_BLF_CHUNK size pieces the buffer
|
|
|
|
|
* can be divided into. Make sure not to truncate any pieces.
|
|
|
|
|
* map_size is the size of the bitmap needed to describe the
|
|
|
|
|
* chunks of the buffer.
|
|
|
|
|
*
|
|
|
|
|
* Discontiguous buffer support follows the layout of the underlying
|
|
|
|
|
* buffer. This makes the implementation as simple as possible.
|
|
|
|
|
*/
|
2020-01-09 01:21:22 +08:00
|
|
|
xfs_buf_item_get_format(bip, bp->b_map_count);
|
2012-06-22 16:50:12 +08:00
|
|
|
|
|
|
|
|
for (i = 0; i < bip->bli_format_count; i++) {
|
|
|
|
|
chunks = DIV_ROUND_UP(BBTOB(bp->b_maps[i].bm_len),
|
|
|
|
|
XFS_BLF_CHUNK);
|
|
|
|
|
map_size = DIV_ROUND_UP(chunks, NBWORD);
|
|
|
|
|
|
2020-01-08 08:12:24 +08:00
|
|
|
if (map_size > XFS_BLF_DATAMAP_SIZE) {
|
2021-10-13 02:09:23 +08:00
|
|
|
kmem_cache_free(xfs_buf_item_cache, bip);
|
2020-01-08 08:12:24 +08:00
|
|
|
xfs_err(mp,
|
|
|
|
|
"buffer item dirty bitmap (%u uints) too small to reflect %u bytes!",
|
|
|
|
|
map_size,
|
|
|
|
|
BBTOB(bp->b_maps[i].bm_len));
|
|
|
|
|
return -EFSCORRUPTED;
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-22 16:50:12 +08:00
|
|
|
bip->bli_formats[i].blf_type = XFS_LI_BUF;
|
|
|
|
|
bip->bli_formats[i].blf_blkno = bp->b_maps[i].bm_bn;
|
|
|
|
|
bip->bli_formats[i].blf_len = bp->b_maps[i].bm_len;
|
|
|
|
|
bip->bli_formats[i].blf_map_size = map_size;
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-01-25 05:38:48 +08:00
|
|
|
bp->b_log_item = bip;
|
2015-08-25 08:05:13 +08:00
|
|
|
xfs_buf_hold(bp);
|
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Mark bytes first through last inclusive as dirty in the buf
|
|
|
|
|
* item's bitmap.
|
|
|
|
|
*/
|
2013-10-29 19:11:58 +08:00
|
|
|
static void
|
2012-06-22 16:50:12 +08:00
|
|
|
xfs_buf_item_log_segment(
|
2005-04-17 06:20:36 +08:00
|
|
|
uint first,
|
2012-06-22 16:50:12 +08:00
|
|
|
uint last,
|
|
|
|
|
uint *map)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
|
uint first_bit;
|
|
|
|
|
uint last_bit;
|
|
|
|
|
uint bits_to_set;
|
|
|
|
|
uint bits_set;
|
|
|
|
|
uint word_num;
|
|
|
|
|
uint *wordp;
|
|
|
|
|
uint bit;
|
|
|
|
|
uint end_bit;
|
|
|
|
|
uint mask;
|
|
|
|
|
|
2020-01-08 08:12:24 +08:00
|
|
|
ASSERT(first < XFS_BLF_DATAMAP_SIZE * XFS_BLF_CHUNK * NBWORD);
|
|
|
|
|
ASSERT(last < XFS_BLF_DATAMAP_SIZE * XFS_BLF_CHUNK * NBWORD);
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* Convert byte offsets to bit numbers.
|
|
|
|
|
*/
|
2010-05-07 09:05:19 +08:00
|
|
|
first_bit = first >> XFS_BLF_SHIFT;
|
|
|
|
|
last_bit = last >> XFS_BLF_SHIFT;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Calculate the total number of bits to be set.
|
|
|
|
|
*/
|
|
|
|
|
bits_to_set = last_bit - first_bit + 1;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Get a pointer to the first word in the bitmap
|
|
|
|
|
* to set a bit in.
|
|
|
|
|
*/
|
|
|
|
|
word_num = first_bit >> BIT_TO_WORD_SHIFT;
|
2012-06-22 16:50:12 +08:00
|
|
|
wordp = &map[word_num];
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Calculate the starting bit in the first word.
|
|
|
|
|
*/
|
|
|
|
|
bit = first_bit & (uint)(NBWORD - 1);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* First set any bits in the first word of our range.
|
|
|
|
|
* If it starts at bit 0 of the word, it will be
|
|
|
|
|
* set below rather than here. That is what the variable
|
|
|
|
|
* bit tells us. The variable bits_set tracks the number
|
|
|
|
|
* of bits that have been set so far. End_bit is the number
|
|
|
|
|
* of the last bit to be set in this word plus one.
|
|
|
|
|
*/
|
|
|
|
|
if (bit) {
|
2018-06-07 22:54:02 +08:00
|
|
|
end_bit = min(bit + bits_to_set, (uint)NBWORD);
|
2016-09-14 05:41:16 +08:00
|
|
|
mask = ((1U << (end_bit - bit)) - 1) << bit;
|
2005-04-17 06:20:36 +08:00
|
|
|
*wordp |= mask;
|
|
|
|
|
wordp++;
|
|
|
|
|
bits_set = end_bit - bit;
|
|
|
|
|
} else {
|
|
|
|
|
bits_set = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Now set bits a whole word at a time that are between
|
|
|
|
|
* first_bit and last_bit.
|
|
|
|
|
*/
|
|
|
|
|
while ((bits_to_set - bits_set) >= NBWORD) {
|
2019-11-07 00:58:33 +08:00
|
|
|
*wordp = 0xffffffff;
|
2005-04-17 06:20:36 +08:00
|
|
|
bits_set += NBWORD;
|
|
|
|
|
wordp++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Finally, set any bits left to be set in one last partial word.
|
|
|
|
|
*/
|
|
|
|
|
end_bit = bits_to_set - bits_set;
|
|
|
|
|
if (end_bit) {
|
2016-09-14 05:41:16 +08:00
|
|
|
mask = (1U << end_bit) - 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
*wordp |= mask;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-22 16:50:12 +08:00
|
|
|
/*
|
|
|
|
|
* Mark bytes first through last inclusive as dirty in the buf
|
|
|
|
|
* item's bitmap.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
xfs_buf_item_log(
|
2018-01-25 05:38:48 +08:00
|
|
|
struct xfs_buf_log_item *bip,
|
2012-06-22 16:50:12 +08:00
|
|
|
uint first,
|
|
|
|
|
uint last)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
uint start;
|
|
|
|
|
uint end;
|
|
|
|
|
struct xfs_buf *bp = bip->bli_buf;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* walk each buffer segment and mark them dirty appropriately.
|
|
|
|
|
*/
|
|
|
|
|
start = 0;
|
|
|
|
|
for (i = 0; i < bip->bli_format_count; i++) {
|
|
|
|
|
if (start > last)
|
|
|
|
|
break;
|
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 15:38:12 +08:00
|
|
|
end = start + BBTOB(bp->b_maps[i].bm_len) - 1;
|
|
|
|
|
|
|
|
|
|
/* skip to the map that includes the first byte to log */
|
2012-06-22 16:50:12 +08:00
|
|
|
if (first > end) {
|
|
|
|
|
start += BBTOB(bp->b_maps[i].bm_len);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 15:38:12 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Trim the range to this segment and mark it in the bitmap.
|
|
|
|
|
* Note that we must convert buffer offsets to segment relative
|
|
|
|
|
* offsets (e.g., the first byte of each segment is byte 0 of
|
|
|
|
|
* that segment).
|
|
|
|
|
*/
|
2012-06-22 16:50:12 +08:00
|
|
|
if (first < start)
|
|
|
|
|
first = start;
|
|
|
|
|
if (end > last)
|
|
|
|
|
end = last;
|
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 15:38:12 +08:00
|
|
|
xfs_buf_item_log_segment(first - start, end - start,
|
2012-06-22 16:50:12 +08:00
|
|
|
&bip->bli_formats[i].blf_data_map[0]);
|
|
|
|
|
|
xfs: fix broken multi-fsb buffer logging
Multi-block buffers are logged based on buffer offset in
xfs_trans_log_buf(). xfs_buf_item_log() ultimately walks each mapping in
the buffer and marks the associated range to be logged in the
xfs_buf_log_format bitmap for that mapping. This code is broken,
however, in that it marks the actual buffer offsets of the associated
range in each bitmap rather than shifting to the byte range for that
particular mapping.
For example, on a 4k fsb fs, buffer offset 4096 refers to the first byte
of the second mapping in the buffer. This means byte 0 of the second log
format bitmap should be tagged as dirty. Instead, the current code marks
byte offset 4096 of the second log format bitmap, which is invalid and
potentially out of range of the mapping.
As a result of this, the log item format code invoked at transaction
commit time is not be able to correctly identify what parts of the
buffer to copy into log vectors. This can lead to NULL log vector
pointer dereferences in CIL push context if the item format code was not
able to locate any dirty ranges at all. This crash has been reproduced
on a 4k FSB filesystem using 16k directory blocks where an unlink
operation happened not to log anything in the first block of the
mapping. The logged offsets were all over 4k, marked as such in the
subsequent log format mappings, and thus left the transaction with an
xfs_log_item that is marked DIRTY but without any logged regions.
Further, even when the logged regions are marked correctly in the buffer
log format bitmaps, the format code doesn't copy the correct ranges of
the buffer into the log. This means that any logged region beyond the
first block of a multi-block buffer is subject to corruption after a
crash and log recovery sequence. This is due to a failure to convert the
mapping bm_len field from basic blocks to bytes in the buffer offset
tracking code in xfs_buf_item_format().
Update xfs_buf_item_log() to convert buffer offsets to segment relative
offsets when logging multi-block buffers. This ensures that the modified
regions of a buffer are logged correctly and avoids the aforementioned
crash. Also update xfs_buf_item_format() to correctly track the source
offset into the buffer for the log vector formatting code. This ensures
that the correct data is copied into the log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-06-01 15:38:12 +08:00
|
|
|
start += BBTOB(bp->b_maps[i].bm_len);
|
2012-06-22 16:50:12 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-08-30 01:08:37 +08:00
|
|
|
/*
|
|
|
|
|
* Return true if the buffer has any ranges logged/dirtied by a transaction,
|
|
|
|
|
* false otherwise.
|
|
|
|
|
*/
|
|
|
|
|
bool
|
|
|
|
|
xfs_buf_item_dirty_format(
|
|
|
|
|
struct xfs_buf_log_item *bip)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < bip->bli_format_count; i++) {
|
|
|
|
|
if (!xfs_bitmap_empty(bip->bli_formats[i].blf_data_map,
|
|
|
|
|
bip->bli_formats[i].blf_map_size))
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2008-09-17 14:52:13 +08:00
|
|
|
STATIC void
|
|
|
|
|
xfs_buf_item_free(
|
2018-01-25 05:38:48 +08:00
|
|
|
struct xfs_buf_log_item *bip)
|
2008-09-17 14:52:13 +08:00
|
|
|
{
|
2012-06-22 16:50:12 +08:00
|
|
|
xfs_buf_item_free_format(bip);
|
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-22 07:52:35 +08:00
|
|
|
kmem_free(bip->bli_item.li_lv_shadow);
|
2021-10-13 02:09:23 +08:00
|
|
|
kmem_cache_free(xfs_buf_item_cache, bip);
|
2008-09-17 14:52:13 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2020-06-30 05:48:47 +08:00
|
|
|
* xfs_buf_item_relse() is called when the buf log item is no longer needed.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
xfs_buf_item_relse(
|
2020-12-17 08:07:34 +08:00
|
|
|
struct xfs_buf *bp)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2018-01-25 05:38:48 +08:00
|
|
|
struct xfs_buf_log_item *bip = bp->b_log_item;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-12-15 07:14:59 +08:00
|
|
|
trace_xfs_buf_item_relse(bp, _RET_IP_);
|
2019-12-18 05:50:26 +08:00
|
|
|
ASSERT(!test_bit(XFS_LI_IN_AIL, &bip->bli_item.li_flags));
|
2009-12-15 07:14:59 +08:00
|
|
|
|
xfs: fix super block buf log item UAF during force shutdown
xfs log io error will trigger xlog shut down, and end_io worker call
xlog_state_shutdown_callbacks to unpin and release the buf log item.
The race condition is that when there are some thread doing transaction
commit and happened not to be intercepted by xlog_is_shutdown, then,
these log item will be insert into CIL, when unpin and release these
buf log item, UAF will occur. BTW, add delay before `xlog_cil_commit`
can increase recurrence probability.
The following call graph actually encountered this bad situation.
fsstress io end worker kworker/0:1H-216
xlog_ioend_work
->xlog_force_shutdown
->xlog_state_shutdown_callbacks
->xlog_cil_process_committed
->xlog_cil_committed
->xfs_trans_committed_bulk
->xfs_trans_apply_sb_deltas ->li_ops->iop_unpin(lip, 1);
->xfs_trans_getsb
->_xfs_trans_bjoin
->xfs_buf_item_init
->if (bip) { return 0;} //relog
->xlog_cil_commit
->xlog_cil_insert_items //insert into CIL
->xfs_buf_ioend_fail(bp);
->xfs_buf_ioend
->xfs_buf_item_done
->xfs_buf_item_relse
->xfs_buf_item_free
when cil push worker gather percpu cil and insert super block buf log item
into ctx->log_items then uaf occurs.
==================================================================
BUG: KASAN: use-after-free in xlog_cil_push_work+0x1c8f/0x22f0
Write of size 8 at addr ffff88801800f3f0 by task kworker/u4:4/105
CPU: 0 PID: 105 Comm: kworker/u4:4 Tainted: G W
6.1.0-rc1-00001-g274115149b42 #136
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: xfs-cil/sda xlog_cil_push_work
Call Trace:
<TASK>
dump_stack_lvl+0x4d/0x66
print_report+0x171/0x4a6
kasan_report+0xb3/0x130
xlog_cil_push_work+0x1c8f/0x22f0
process_one_work+0x6f9/0xf70
worker_thread+0x578/0xf30
kthread+0x28c/0x330
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 2145:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_slab_alloc+0x54/0x60
kmem_cache_alloc+0x14a/0x510
xfs_buf_item_init+0x160/0x6d0
_xfs_trans_bjoin+0x7f/0x2e0
xfs_trans_getsb+0xb6/0x3f0
xfs_trans_apply_sb_deltas+0x1f/0x8c0
__xfs_trans_commit+0xa25/0xe10
xfs_symlink+0xe23/0x1660
xfs_vn_symlink+0x157/0x280
vfs_symlink+0x491/0x790
do_symlinkat+0x128/0x220
__x64_sys_symlink+0x7a/0x90
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 216:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
__kasan_slab_free+0x105/0x1a0
kmem_cache_free+0xb6/0x460
xfs_buf_ioend+0x1e9/0x11f0
xfs_buf_item_unpin+0x3d6/0x840
xfs_trans_committed_bulk+0x4c2/0x7c0
xlog_cil_committed+0xab6/0xfb0
xlog_cil_process_committed+0x117/0x1e0
xlog_state_shutdown_callbacks+0x208/0x440
xlog_force_shutdown+0x1b3/0x3a0
xlog_ioend_work+0xef/0x1d0
process_one_work+0x6f9/0xf70
worker_thread+0x578/0xf30
kthread+0x28c/0x330
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff88801800f388
which belongs to the cache xfs_buf_item of size 272
The buggy address is located 104 bytes inside of
272-byte region [ffff88801800f388, ffff88801800f498)
The buggy address belongs to the physical page:
page:ffffea0000600380 refcount:1 mapcount:0 mapping:0000000000000000
index:0xffff88801800f208 pfn:0x1800e
head:ffffea0000600380 order:1 compound_mapcount:0 compound_pincount:0
flags: 0x1fffff80010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 001fffff80010200 ffffea0000699788 ffff88801319db50 ffff88800fb50640
raw: ffff88801800f208 000000000015000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88801800f280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801800f300: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88801800f380: fc fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88801800f400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801800f480: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Disabling lock debugging due to kernel taint
Signed-off-by: Guo Xuenan <guoxuenan@huawei.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2022-12-01 01:25:46 +08:00
|
|
|
if (atomic_read(&bip->bli_refcount))
|
|
|
|
|
return;
|
2018-01-25 05:38:48 +08:00
|
|
|
bp->b_log_item = NULL;
|
2008-09-17 14:52:13 +08:00
|
|
|
xfs_buf_rele(bp);
|
|
|
|
|
xfs_buf_item_free(bip);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2020-09-02 01:55:29 +08:00
|
|
|
void
|
2020-06-30 05:49:14 +08:00
|
|
|
xfs_buf_item_done(
|
2020-06-30 05:48:48 +08:00
|
|
|
struct xfs_buf *bp)
|
|
|
|
|
{
|
2020-06-30 05:49:14 +08:00
|
|
|
/*
|
|
|
|
|
* If we are forcibly shutting down, this may well be off the AIL
|
|
|
|
|
* already. That's because we simulate the log-committed callbacks to
|
|
|
|
|
* unpin these buffers. Or we may never have put this item on AIL
|
|
|
|
|
* because of the transaction was aborted forcibly.
|
|
|
|
|
* xfs_trans_ail_delete() takes care of these.
|
|
|
|
|
*
|
|
|
|
|
* Either way, AIL is useless if we're forcing a shutdown.
|
2020-09-02 01:55:46 +08:00
|
|
|
*
|
|
|
|
|
* Note that log recovery writes might have buffer items that are not on
|
|
|
|
|
* the AIL even when the file system is not shut down.
|
2020-06-30 05:49:14 +08:00
|
|
|
*/
|
2020-09-02 01:55:46 +08:00
|
|
|
xfs_trans_ail_delete(&bp->b_log_item->bli_item,
|
2020-09-02 01:55:46 +08:00
|
|
|
(bp->b_flags & _XBF_LOGRECOVERY) ? 0 :
|
2020-09-02 01:55:46 +08:00
|
|
|
SHUTDOWN_CORRUPT_INCORE);
|
|
|
|
|
xfs_buf_item_relse(bp);
|
2020-06-30 05:48:46 +08:00
|
|
|
}
|
