From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 0/2] btrfs: fix data corruption/rsv leak in subpage zoned cases
Date: Sat, 11 May 2024 08:34:28 +0930 [thread overview]
Message-ID: <b3315737-894a-4de3-8979-28ce2ee698f8@suse.com> (raw)
In-Reply-To: <cover.1709781158.git.wqu@suse.com>
在 2024/3/7 13:46, Qu Wenruo 写道:
> [CHANGELOG]
> v3:
> - Use the minimal fsstress workload with trace_printk() output to
> explain the bug better
>
> v2:
> - Update the commit message for the first patch
> As there is something wrong with the ASCII art of the memory layout.
>
> [REPO]
> https://github.com/adam900710/linux/tree/subpage_delalloc
Wait, it looks like there are more preparation patches not yet merged.
I'll rebase with all needed patches in one go.
Otherwise it looks like it's causing a lot of more problems reviewing.
Thanks,
Qu
>
> 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 further 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(-)
>
prev parent reply other threads:[~2024-05-10 23:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 3:16 [PATCH v3 0/2] btrfs: fix data corruption/rsv leak in subpage zoned cases Qu Wenruo
2024-03-07 3:16 ` [PATCH v3 1/2] btrfs: do not clear page dirty inside extent_write_locked_range() Qu Wenruo
2024-03-07 3:16 ` [PATCH v3 2/2] btrfs: make extent_write_locked_range() to handle subpage writeback correctly Qu Wenruo
2024-05-10 23:04 ` Qu Wenruo [this message]
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=b3315737-894a-4de3-8979-28ce2ee698f8@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).