From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>,
Qu Wenruo <quwenruo.btrfs@gmx.com>,
clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] btrfs: remove btrfs_writepage_cow_fixup
Date: Sat, 25 Jun 2022 11:11:43 +0200 [thread overview]
Message-ID: <20220625091143.GA23118@lst.de> (raw)
In-Reply-To: <20220624130750.cu26nnm6hjrru4zd@quack3.lan>
On Fri, Jun 24, 2022 at 03:07:50PM +0200, Jan Kara wrote:
> I'm not sure I get the context 100% right but pages getting randomly dirty
> behind filesystem's back can still happen - most commonly with RDMA and
> similar stuff which calls set_page_dirty() on pages it has got from
> pin_user_pages() once the transfer is done. page_maybe_dma_pinned() should
> be usable within filesystems to detect such cases and protect the
> filesystem but so far neither me nor John Hubbart has got to implement this
> in the generic writeback infrastructure + some filesystem as a sample case
> others could copy...
Well, so far the strategy elsewhere seems to be to just ignore pages
only dirtied through get_user_pages. E.g. iomap skips over pages
reported as holes, and ext4_writepage complains about pages without
buffers and then clears the dirty bit and continues.
I'm kinda surprised that btrfs wants to treat this so special
especially as more of the btrfs page and sub-page status will be out
of date as well.
next prev parent reply other threads:[~2022-06-25 9:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220624122334.80603-1-hch@lst.de>
[not found] ` <7c30b6a4-e628-baea-be83-6557750f995a@gmx.com>
2022-06-24 12:51 ` [PATCH] btrfs: remove btrfs_writepage_cow_fixup Christoph Hellwig
2022-06-24 13:07 ` Jan Kara
2022-06-24 13:19 ` Qu Wenruo
2022-06-24 13:40 ` Jan Kara
2022-06-24 13:56 ` Qu Wenruo
2022-06-27 10:15 ` Jan Kara
2022-06-25 9:11 ` Christoph Hellwig [this message]
2022-06-27 10:19 ` Jan Kara
2022-06-28 0:24 ` Qu Wenruo
2022-06-28 8:00 ` Jan Kara
2022-06-29 1:33 ` Qu Wenruo
2022-06-29 10:03 ` Jan Kara
2022-06-28 11:53 ` David Sterba
2022-06-29 7:58 ` Christoph Hellwig
2022-07-05 14:21 ` Gerald Schaefer
2022-06-28 11:46 ` David Sterba
2022-06-28 14:29 ` Chris Mason
2022-06-29 1:20 ` Qu Wenruo
2022-06-29 8:40 ` Christoph Hellwig
2022-06-29 8:38 ` Christoph Hellwig
2022-06-29 9:45 ` Jan Kara
2022-06-29 13:59 ` Christoph Hellwig
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=20220625091143.GA23118@lst.de \
--to=hch@lst.de \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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 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 NNTP newsgroup(s).