From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Qu Wenruo <wqu@suse.com>,
linux-fsdevel@vger.kernel.org,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: About using on-stack fsdata pointer for write_begin() and write_end() callbacks
Date: Tue, 12 Nov 2024 16:43:03 +1030 [thread overview]
Message-ID: <5afdbcb2-99ee-48de-88a6-afe910329a04@gmx.com> (raw)
In-Reply-To: <ZzLwYZqwf7k5GlRV@infradead.org>
在 2024/11/12 16:36, Christoph Hellwig 写道:
> On Tue, Nov 12, 2024 at 04:33:56PM +1030, Qu Wenruo wrote:
>> IIRC it's related to the get_user_page() shenanigans but not 100% sure.
>
> While there might be a few stragglers left, everyone should be using
> pin_user_pages when manipulating page contents. The long tolerated
> just pin and mark dirty is officially a bug now.
Great to know that.
>
>> I'm talking about the iomap_set_range_dirty() call inside
>> iomap_writepage_map(), for the "if (i_blocks_per_folio() > 1)" branch.
>
> That does not set the page dirty. It propagatates the per-folio
> dirty state into the per-block dirty bitmap allocated in the line
> above.
I know, I just want to say it's marking the whole folio to be written back.
And in that out-of-band case, shouldn't we error out now instead of
marking the range to be written back?
Especially such out-of-band folio is unstable and can lead to other
problems, like content change halfway and causing csum mismatch.
And if that's the case, I think it will be much easier for btrfs to get
rid of its cow fixup workaround.
Thanks,
Qu
prev parent reply other threads:[~2024-11-12 6:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 4:27 About using on-stack fsdata pointer for write_begin() and write_end() callbacks Qu Wenruo
2024-11-11 5:52 ` Christoph Hellwig
2024-11-11 7:36 ` Qu Wenruo
2024-11-12 5:05 ` Christoph Hellwig
2024-11-12 5:31 ` Qu Wenruo
2024-11-12 5:41 ` Christoph Hellwig
2024-11-12 6:03 ` Qu Wenruo
2024-11-12 6:06 ` Christoph Hellwig
2024-11-12 6:13 ` 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=5afdbcb2-99ee-48de-88a6-afe910329a04@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=wqu@suse.com \
/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.