public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/2] btrfs: error handling fixes for extent_writepage()
Date: Tue, 26 Nov 2024 16:59:22 +1030	[thread overview]
Message-ID: <cover.1732596971.git.wqu@suse.com> (raw)

Now with the new compressed write support and the incoming partial
uptodate folio and inline write support, it's easier and easier to hit
crashes for test cases likes generic/750, when the sector size is
smaller than page size.

The main symptom is ordered extent double accounting, causing various
problems mostly kernel warning and crashes (for debug builds).

The direct cause the failure from writepage_delalloc() with -ENOSPC,
which is another rabbit hole, but here we need to focus on the error
handling.

All the call traces points to the btrfs_mark_ordered_io_finished()
inside extent_writepage() for error handling.

It turns out that that unconditional, full folio cleanup is no doubt the
root cause, and there are two error paths leading to the situation:

- btrfs_run_delalloc_range() failure
  Which can lead some delalloc ranges are submitted asynchronously
  (compression mostly), and we try to clean up those which we shouldn't.

  This is the most common one, as I'm hitting quite some -ENOSPC during
  my fstests runs, and all the hang/crashes are following such errors.

- submit_one_sector() failure
  This is much rare, as I haven't really hit one.
  But the idea is pretty much the same, so we should not touch ranges we
  shouldn't.

Both fixes are similar, by moving the btrfs_mark_ordered_io_finished()
calls for error handling into each function, so that we can avoid
touching async extents.

Although these fixes are mostly for backports, the proper fix in the end
would be reworking how we handle dirty folio writeback.

The current way is map-map-map, then submit-submit-submit (run delalloc
for every dirty sector of the folio, then submit all dirty sectors).

The planned new fix would be more like iomap to go
map-submit-map-submit-map-submit (run one delalloc, then immeidately submit
it).

Qu Wenruo (2):
  btrfs: handle btrfs_run_delalloc_range() errors correctly
  btrfs: handle submit_one_sector() error inside extent_writepage_io()

 fs/btrfs/extent_io.c | 71 +++++++++++++++++++++++++++++++++-----------
 1 file changed, 53 insertions(+), 18 deletions(-)

-- 
2.47.0


             reply	other threads:[~2024-11-26  6:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26  6:29 Qu Wenruo [this message]
2024-11-26  6:29 ` [PATCH 1/2] btrfs: handle btrfs_run_delalloc_range() errors correctly Qu Wenruo
2024-11-26  6:29 ` [PATCH 2/2] btrfs: handle submit_one_sector() error inside extent_writepage_io() Qu Wenruo

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.1732596971.git.wqu@suse.com \
    --to=wqu@suse.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