Re: Removing ->dirty_folio

[Matthew Wilcox <willy@infradead.org>]

On Tue, Aug 25, 2026 at 08:08:48AM +0930, Qu Wenruo wrote:
> > 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.
> 
> This may make COW more complex.

It's probably wise to be explicit when talking about COW.  Anyone from
the MM side of the house is probably thinking "but this is only relevant
for shared writable mmap and we don't do a COW".  You're talking about
filesystems doing a COW of the on-disc data, not about the MM COWing the
pagecache page into an anonymous page.

> For folio_maybe_dma_pinned() case, we will need to do extra space
> reservation similar to page_mkdirty() again, so that the folio can be
> written back again.

Yes, you will.

> I'm not sure if we will have a good timing for re-reserving space inside
> btrfs.

Why is it hard to do it immediately at writeback time?  I think you're
in an even less restrictive locking environment than page_mkwrite is
called in because you're not under any MM locks.  According to
Documentation/filesystems/locking.rst, ->writepages is called with
absolutely no locks held.

> Would it be possible for MM/VFS layer to trigger page_mkdirty() instead?

Actually ... no, because the VFS no longer knows which pages in the
folio are dirty.  That's information the MM had, and communicated to
the FS which (if it cares) has stored in its folio->private.  But the
VFS no longer has access to that information.