From: Matthew Wilcox <willy@infradead.org>
To: Pedro Falcato <pfalcato@suse.de>, Christoph Hellwig <hch@lst.de>,
Jann Horn <jannh@google.com>, David Howells <dhowells@redhat.com>,
John Hubbard <jhubbard@nvidia.com>, Jan Kara <jack@suse.cz>,
Rik van Riel <riel@surriel.com>, Qu Wenruo <wqu@suse.com>,
"Darrick J. Wong" <djwong@kernel.org>,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-xfs@vger.kernel.org
Subject: Removing ->dirty_folio
Date: Mon, 24 Aug 2026 20:08:06 +0100 [thread overview]
Message-ID: <aoyWln-Gt-yvZQkE@casper.infradead.org> (raw)
I think it's time to remove folio_mark_dirty(), ->dirty_folio() and so on.
This is not how filesystems want to be informed of folio dirtying.
It was fine for ext2, but anything that's journalled or COW has work
to do before the folio is made dirty, and it's hard to do that work
under the page table spinlock (not all callers hold that lock, but the
filesystem has to be able to handle the cases where it is.
Filesystems want the page_mkwrite() entry point to be how they find out
about a folio being dirtied -- and that works great! Except that we
can writeback the folio for a number of reasons. If it's been dirtied
due to a shared writable mmap, that's fine; we map the folio read-only
and any subsequent writes will re-enter the page_mkwrite path.
The problem is GUP. We have no way to force the GUP caller to go
through page_mkwrite again. So instead we make the GUP caller call
folio_mark_dirty_lock() which many just don't, and generally we get away
with it. But it's a bug, and a bad interface.
There's also the problem that GUP users bypass the folio_wait_stable()
mechanism. If a page is written to while somebody is creating a
checksum over that page, the checksum will be corrupted. If we want
to fix this, we have to bounce-buffer the page. There's no way to
prevent or delay a GUP user from writing to the page. Enjoy your RAID.
My proposal is this:
- Fileystems take note of folio_maybe_dma_pinned() during writeback.
If it's true, do the writeback, but retain/recreate whatever data
structures you need in order to write the folio again; behave as if
->page_mkdirty() had been called again for each page in the folio is
marked as dirty.
- The MM behaves similarly; we do not clear the writeback flag for
folio_maybe_dma_pinned().
This will have the effect of writing pinned folios back every time the
inode is scheduled for writeback. But since we have no idea whether
the folio is actually dirty (because the GUP user won't tell us),
this is the correct behaviour.
I'm probably missing some stuff here. Let me know.
next reply other threads:[~2026-08-24 19:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 19:08 Matthew Wilcox [this message]
2026-08-24 19:25 ` Removing ->dirty_folio John Hubbard
2026-08-24 19:43 ` Matthew Wilcox
2026-08-24 19:51 ` John Hubbard
2026-08-24 21:05 ` Matthew Wilcox
2026-08-25 7:59 ` Pedro Falcato
2026-08-24 19:33 ` Rik van Riel
2026-08-25 8:21 ` David Hildenbrand (Arm)
2026-08-24 21:27 ` Boris Burkov
2026-08-25 19:47 ` Matthew Wilcox
2026-08-24 22:38 ` Qu Wenruo
2026-08-25 19:26 ` Matthew Wilcox
2026-08-25 22:33 ` Qu Wenruo
2026-08-26 4:53 ` Christoph Hellwig
2026-08-26 8:01 ` Christoph Hellwig
2026-08-25 6:48 ` David Howells
2026-08-25 19:16 ` Matthew Wilcox
2026-08-25 7:39 ` Christoph Hellwig
2026-08-25 19:14 ` Matthew Wilcox
2026-08-25 8:25 ` Pedro Falcato
2026-08-25 18:35 ` Matthew Wilcox
2026-08-26 7:54 ` Christoph Hellwig
2026-08-25 19:35 ` Jann Horn
2026-08-25 19:54 ` Matthew Wilcox
2026-08-25 20:06 ` Jann Horn
2026-08-26 0:02 ` Matthew Wilcox
2026-08-26 5:07 ` Christoph Hellwig
2026-08-26 7:42 ` 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=aoyWln-Gt-yvZQkE@casper.infradead.org \
--to=willy@infradead.org \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=jhubbard@nvidia.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=pfalcato@suse.de \
--cc=riel@surriel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox