Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH v2 0/5] Serious fixes for different error paths
Date: Thu, 14 Jan 2021 14:02:41 -0500	[thread overview]
Message-ID: <cover.1610650736.git.josef@toxicpanda.com> (raw)

v1->v2:
- Rebased onto misc-next, dropping everything that's been merged so far.
- Fixed "btrfs: splice remaining dirty_bg's onto the transaction dirty bg list"
  to handle the btrfs_alloc_path() failure and cleaned up the error handling as
  a result of that change.
- dropped "btrfs: don't clear ret in btrfs_start_dirty_block_groups" as I fixed
  it differently in "btrfs: splice remaining dirty_bg's onto the transaction
  dirty bg list"
- Added a link to Zygo's original report in "btrfs: add asserts for deleting
  backref cache nodes".
- Clarified the error condition that lead to the WARN_ON() in the changelog for
  "btrfs: do not WARN_ON() if we can't find the reloc root".
- Added the stack trace that the error injection triggered in order to get the
  error that happened in "btrfs: abort the transaction if we fail to inc ref in
  btrfs_copy_root".

--- Original email ---
Hello,

A lot of these were in previous versions of the relocation error handling
patches.  I added a few since the last go around.  All of these do not rely on
the error handling patches, and some of them are quite important otherwise we
get corruption if we get errors in certain spots.  There's also a few lockdep
fixes and such.  These really need to go in ASAP, regardless of when the
relocation error handling patches are merged.  They're mostly small and self
contained, the only "big" one being the one that tracks the root owner for
relocation reads, which is to resolve the remaining class of lockdep errors we
get because of an improper lockdep class set on the extent buffer.  Thanks,

Josef

Josef Bacik (5):
  btrfs: fix reloc root leak with 0 ref reloc roots on recovery
  btrfs: splice remaining dirty_bg's onto the transaction dirty bg list
  btrfs: do not WARN_ON() if we can't find the reloc root
  btrfs: add asserts for deleting backref cache nodes
  btrfs: abort the transaction if we fail to inc ref in btrfs_copy_root

 fs/btrfs/backref.c     |  2 +-
 fs/btrfs/backref.h     |  9 ++++++---
 fs/btrfs/block-group.c | 19 ++++++++++++-------
 fs/btrfs/ctree.c       |  5 +++--
 fs/btrfs/relocation.c  |  4 +---
 5 files changed, 23 insertions(+), 16 deletions(-)

-- 
2.26.2


             reply	other threads:[~2021-01-14 19:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 19:02 Josef Bacik [this message]
2021-01-14 19:02 ` [PATCH v2 1/5] btrfs: fix reloc root leak with 0 ref reloc roots on recovery Josef Bacik
2021-01-14 19:02 ` [PATCH v2 2/5] btrfs: splice remaining dirty_bg's onto the transaction dirty bg list Josef Bacik
2021-01-14 19:02 ` [PATCH v2 3/5] btrfs: do not WARN_ON() if we can't find the reloc root Josef Bacik
2021-01-14 19:02 ` [PATCH v2 4/5] btrfs: add asserts for deleting backref cache nodes Josef Bacik
2021-01-14 19:02 ` [PATCH v2 5/5] btrfs: abort the transaction if we fail to inc ref in btrfs_copy_root Josef Bacik
2021-01-26 16:41 ` [PATCH v2 0/5] Serious fixes for different error paths David Sterba

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=cover.1610650736.git.josef@toxicpanda.com \
    --to=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@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