From: Jan Kara <jack@suse.cz>
To: <linux-fsdevel@vger.kernel.org>
Cc: <linux-block@vger.kernel.org>, <linux-mm@kvack.org>,
John Hubbard <jhubbard@nvidia.com>,
David Howells <dhowells@redhat.com>,
David Hildenbrand <david@redhat.com>, Jan Kara <jack@suse.cz>
Subject: [PATCH RFC 0/5] Writeback handling of pinned pages
Date: Thu, 9 Feb 2023 13:31:52 +0100 [thread overview]
Message-ID: <20230209121046.25360-1-jack@suse.cz> (raw)
Hello,
since we are slowly getting into a state where folios used as buffers for
[R]DMA are detectable by folio_maybe_dma_pinned(), I figured it is time we also
address the original problems filesystems had with these pages [1] - namely
that page/folio private data can get reclaimed from the page while it is being
written to by the DMA and also that page contents can be modified while the
page is under writeback.
This patch series is kind of an outline how the solution could look like (so
far only compile tested). The first two patches deal with the reclaim of page
private data for pinned pages. They are IMO no-brainers and actually deal with
99% of the observed issues so we might just separate them and merge them
earlier. The remainder of the series deals with the concern that page contents
can be modified while the page is being written back. What it implements is
that instead we skip page cleaning writeback for pinned pages and if we cannot
avoid writing the page (data integrity writeback), we bite the bullet and
bounce the page.
Note that the conversion of clear_page_dirty_for_io() (and its folio variant)
is kind of rough and providing wbc to the function only in the obvious cases -
that will need a bit more work but OTOH functionally passing NULL just retains
the old behavior + WARNs if we actually see pinned page in the writeback path.
Opinions?
Honza
[1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz
next reply other threads:[~2023-02-09 12:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 12:31 Jan Kara [this message]
2023-02-09 12:31 ` [PATCH 1/5] mm: Do not reclaim private data from pinned page Jan Kara
2023-02-09 16:17 ` Matthew Wilcox
2023-02-10 11:29 ` Jan Kara
2023-02-13 9:55 ` Christoph Hellwig
2023-02-14 13:06 ` Jan Kara
2023-02-14 21:40 ` John Hubbard
2023-02-16 11:56 ` Jan Kara
2023-02-13 9:01 ` David Hildenbrand
2023-02-14 13:00 ` Jan Kara
2023-02-09 12:31 ` [PATCH 2/5] ext4: Drop workaround for mm reclaiming fs private page data Jan Kara
2023-02-09 12:31 ` [PATCH 3/5] mm: Do not try to write pinned folio during memory cleaning writeback Jan Kara
2023-02-10 1:54 ` John Hubbard
2023-02-10 2:10 ` John Hubbard
2023-02-10 10:42 ` Jan Kara
2023-02-10 10:54 ` Jan Kara
2023-02-09 12:31 ` [PATCH 4/5] block: Add support for bouncing pinned pages Jan Kara
2023-02-13 9:59 ` Christoph Hellwig
2023-02-14 13:56 ` Jan Kara
2023-02-15 4:59 ` Dave Chinner
2023-02-15 6:24 ` Christoph Hellwig
2023-02-16 12:33 ` Jan Kara
2023-02-20 6:22 ` Christoph Hellwig
2023-02-27 11:39 ` Jan Kara
2023-02-27 13:36 ` Christoph Hellwig
2023-02-09 12:31 ` [PATCH 5/5] iomap: Bounce pinned pages during writeback Jan Kara
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=20230209121046.25360-1-jack@suse.cz \
--to=jack@suse.cz \
--cc=david@redhat.com \
--cc=dhowells@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.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 NNTP newsgroup(s).