From: Jan Kara <jack@suse.cz>
To: Chris Mason <clm@fb.com>
Cc: Christoph Hellwig <hch@lst.de>, Jan Kara <jack@suse.cz>,
Qu Wenruo <quwenruo.btrfs@gmx.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: Wed, 29 Jun 2022 11:45:47 +0200 [thread overview]
Message-ID: <20220629094547.xa27x7oiuhasglzl@quack3> (raw)
In-Reply-To: <c4af4c49-c537-bd6d-c27e-fe9ed71b9a8e@fb.com>
On Tue 28-06-22 10:29:00, Chris Mason wrote:
> I'd love a proper fix for this on the *_user_pages() side where
> page_mkwrite() style notifications are used all the time. It's just a huge
> change, and my answer so far has always been that using btrfs mmap'd memory
> for this kind of thing isn't a great choice either way.
As Christoph wrote, it isn't a problem that you would not get a
page_mkwrite() notification. That happens just fine. But the problem is
that after that, the page can still get modified after you've removed all
writeable mappings of the page (e.g. by calling page_mkclean() in
clear_page_dirty_for_io()). And there's no way a kernel can provide further
notification for such writes because we've simply handed of the page
physical address to the HW to DMA into.
So the only viable solution is really for the filesystem to detect such
unprotectable pages if it cares and somehow deal with them (skip writeback,
use bounce pages, ...). The good news is that we already have
page_maybe_dma_pinned() call that at least allows detection of such
unprotectable pages.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2022-06-29 9:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 12:23 [PATCH] btrfs: remove btrfs_writepage_cow_fixup Christoph Hellwig
2022-06-24 12:30 ` Qu Wenruo
2022-06-24 12:51 ` 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
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 [this message]
2022-06-29 13:59 ` Christoph Hellwig
2022-06-24 12:49 ` David Sterba
2022-06-24 13:12 ` Qu Wenruo
2022-06-24 13:27 ` David Sterba
2022-06-24 13:50 ` 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=20220629094547.xa27x7oiuhasglzl@quack3 \
--to=jack@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--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