From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs: simple enhancement and fix for delalloc range
Date: Sun, 20 Jul 2025 15:59:08 +0930 [thread overview]
Message-ID: <cover.1752992367.git.wqu@suse.com> (raw)
When debugging the rare DEBUG_WARN() inside btrfs_writepage_cow_fixup(),
I just found several small things to fix/enhance:
- The double boolean parameters of cow_file_range()
A simple enhancement with a single @flags to replace the two booleans.
- Inefficient folio iteration of btrfs_cleanup_ordered_extents()
Enhance that function to support large folios better.
- Wrong parameters for btrfs_cleanup_ordered_extents() of
nocow_one_range()
Due to the wrong parameter (end other than length), we may clear
Ordered flags for range out of our control, which can be some page
under writeback and cause the DEBUG_WARN() inside
btrfs_writepage_cow_fixup().
However the call trace doesn't match the one I hit, which is normally
cow_file_range() failure inside fallback_to_cow().
Not the failure from nocow_one_range().
Although I already have an idea why the DEBUG_WARN() in
btrfs_writepage_cow_fixup() is triggered, the fix will be a little more
complex.
The root cause is that btrfs_cleanup_ordered_extents() is called on
unlocked folios inside run_delalloc_nocow().
As run_delalloc_nocow() can fallback to COW path, and succeeded
cow_file_range() will unlock the folios, we have no other way but to do
the cleanup on unlocked folios.
This has a small race window, where the unlocked folio is already under
writeback, and we cleared the ordered flag halfway, thus triggerring the
error.
The proper fix is to make run_delalloc_nocow() to keep folios
(and io tree range) locked until the full range is finished, just like
how cow_file_range() works, but that will be a much more complex series.
So for now just handle the small-and-simple enhancement and fix.
Qu Wenruo (3):
btrfs: replace double boolean parameters of cow_file_range()
btrfs: make btrfs_cleanup_ordered_extents() to support large folios
btrfs: fix the wrong parameter for btrfs_cleanup_ordered_extents()
fs/btrfs/inode.c | 40 ++++++++++++++++++++++------------------
1 file changed, 22 insertions(+), 18 deletions(-)
--
2.50.0
next reply other threads:[~2025-07-20 6:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-20 6:29 Qu Wenruo [this message]
2025-07-20 6:29 ` [PATCH 1/3] btrfs: replace double boolean parameters of cow_file_range() Qu Wenruo
2025-07-21 20:29 ` Boris Burkov
2025-07-21 22:59 ` Qu Wenruo
2025-07-20 6:29 ` [PATCH 2/3] btrfs: make btrfs_cleanup_ordered_extents() to support large folios Qu Wenruo
2025-07-21 20:32 ` Boris Burkov
2025-07-20 6:29 ` [PATCH 3/3] btrfs: fix the wrong parameter for btrfs_cleanup_ordered_extents() Qu Wenruo
2025-07-21 20:36 ` Boris Burkov
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.1752992367.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.