From: "Darrick J. Wong" <djwong@kernel.org>
To: xfs <linux-xfs@vger.kernel.org>
Subject: [GIT PULL] xfs: improve runtime refcountbt corruption detection
Date: Tue, 1 Nov 2022 09:56:45 -0700 [thread overview]
Message-ID: <Y2FPzdfej3wtvBc5@magnolia> (raw)
Hi me,
Please pull the final versions of the refcountbt infinite loop bugfixes
into for-next.
--D
The following changes since commit 950f0d50ee7138d7e631aefea8528d485426eda6:
xfs: dump corrupt recovered log intent items to dmesg consistently (2022-10-31 08:58:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git tags/refcount-cow-domain-6.1_2022-10-31
for you to fetch changes up to 8b972158afcaa66c538c3ee1d394f096fcd238a8:
xfs: rename XFS_REFC_COW_START to _COWFLAG (2022-10-31 08:58:22 -0700)
----------------------------------------------------------------
xfs: improve runtime refcountbt corruption detection
Fuzz testing of the refcount btree demonstrated a weakness in validation
of refcount btree records during normal runtime. The idea of using the
upper bit of the rc_startblock field to separate the refcount records
into one group for shared space and another for CoW staging extents was
added at the last minute. The incore struct left this bit encoded in
the upper bit of the startblock field, which makes it all too easy for
arithmetic operations to overflow if we don't detect the cowflag
properly.
When I ran a norepair fuzz tester, I was able to crash the kernel on one
of these accidental overflows by fuzzing a key record in a node block,
which broke lookups. To fix the problem, make the domain (shared/cow) a
separate field in the incore record.
Unfortunately, a customer also hit this once in production. Due to bugs
in the kernel running on the VM host, writes to the disk image would
occasionally be lost. Given sufficient memory pressure on the VM guest,
a refcountbt xfs_buf could be reclaimed and later reloaded from the
stale copy on the virtual disk. The stale disk contents were a refcount
btree leaf block full of records for the wrong domain, and this caused
an infinite loop in the guest VM.
v2: actually include the refcount adjust loop invariant checking patch;
move the deferred refcount continuation checks earlier in the series;
break up the megapatch into smaller pieces; fix an uninitialized list
error.
v3: in the continuation check patch, verify the per-ag extent before
converting it to a fsblock
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
----------------------------------------------------------------
Darrick J. Wong (13):
xfs: make sure aglen never goes negative in xfs_refcount_adjust_extents
xfs: create a predicate to verify per-AG extents
xfs: check deferred refcount op continuation parameters
xfs: move _irec structs to xfs_types.h
xfs: refactor refcount record usage in xchk_refcountbt_rec
xfs: track cow/shared record domains explicitly in xfs_refcount_irec
xfs: report refcount domain in tracepoints
xfs: refactor domain and refcount checking
xfs: remove XFS_FIND_RCEXT_SHARED and _COW
xfs: check record domain when accessing refcount records
xfs: fix agblocks check in the cow leftover recovery function
xfs: fix uninitialized list head in struct xfs_refcount_recovery
xfs: rename XFS_REFC_COW_START to _COWFLAG
fs/xfs/libxfs/xfs_ag.h | 15 ++
fs/xfs/libxfs/xfs_alloc.c | 6 +-
fs/xfs/libxfs/xfs_format.h | 22 +--
fs/xfs/libxfs/xfs_refcount.c | 286 ++++++++++++++++++++++++++-----------
fs/xfs/libxfs/xfs_refcount.h | 40 +++++-
fs/xfs/libxfs/xfs_refcount_btree.c | 15 +-
fs/xfs/libxfs/xfs_rmap.c | 9 +-
fs/xfs/libxfs/xfs_types.h | 30 ++++
fs/xfs/scrub/alloc.c | 4 +-
fs/xfs/scrub/ialloc.c | 5 +-
fs/xfs/scrub/refcount.c | 72 ++++------
fs/xfs/xfs_trace.h | 48 +++++--
12 files changed, 368 insertions(+), 184 deletions(-)
reply other threads:[~2022-11-01 16:56 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2FPzdfej3wtvBc5@magnolia \
--to=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox