Re: Removing ->dirty_folio

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2026/8/25 04:38, Matthew Wilcox 写道:
> 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.

That's exactly my previous expectation, really hope this can become true.

> 
> 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.

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.

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

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

>   - 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.
>