From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/2] btrfs: fix data corruption/hang/rsv leak in subpage zoned cases
Date: Wed, 6 Mar 2024 08:45:35 +1030 [thread overview]
Message-ID: <cover.1709676577.git.wqu@suse.com> (raw)
[REPO]
https://github.com/adam900710/linux/tree/subpage_delalloc
The repo includes the subpage delalloc rework, or subpage zoned won't
work at all.
Although my previous subpage delalloc rework fixes quite a lot of
crashes of subpage + zoned support, it's still pretty easy to cause rsv
leak using single thread fsstress.
It turns out that, it's not a simple problem of some rsv leak, but
certain dirty data ranges never got written back and just skipped with
its dirty flags cleared, no wonder that would lead to rsv leak.
The root cause is again in the extent_write_locked_range() function
doing weird subpage incompatible behaviors, especially when it clears
the page dirty flag for the whole page, causing __extent_writepage_io()
unable to locate any dirty ranges to be submitted.
The first patch would solve the problem, meanwhile for the 2nd patch
it's a cleanup, as we will never hit the error for current subpage +
zoned cases.
Qu Wenruo (2):
btrfs: do not clear page dirty inside extent_write_locked_range()
btrfs: make extent_write_locked_range() to handle subpage writeback
correctly
fs/btrfs/extent_io.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--
2.44.0
next reply other threads:[~2024-03-05 22:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 22:15 Qu Wenruo [this message]
2024-03-05 22:15 ` [PATCH 1/2] btrfs: do not clear page dirty inside extent_write_locked_range() Qu Wenruo
2024-03-05 22:15 ` [PATCH 2/2] btrfs: make extent_write_locked_range() to handle subpage writeback correctly 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.1709676577.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.