public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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