Re: Removing ->dirty_folio

[Pedro Falcato <pfalcato@suse.de>]

On Mon, Aug 24, 2026 at 08:08:06PM +0100, Matthew Wilcox wrote:
> 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

I don't think you can do this for stable writes. It's probably ok for
!stable writes filesystem stacks, as long as the filesystem & writeback
can handle making no progress at all. But since stable writes' writeback
can't race with "writes", I don't think you can Just Do It as long as the
folio is DMA pinned.

Perhaps we should give up trying to writeback these folios, and start
writeback right after they're unpinned? at least on the stable case.

>    marked as dirty.
>  - The MM behaves similarly; we do not clear the writeback flag for
>    folio_maybe_dma_pinned().

This sounds like a problem. You don't want users expecting writeback to make
progress to suddenly stall on e.g folio_wait_writeback() indefinitely.

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

I don't quite understand what your plan for getting rid of dirty_folio,
et al is. page_mkwrite has the fatal flaw of being directly tied to VM
page faults; I don't think it's the ideal interface for notifying filesystems.
It's also the case that page_mkwrite can trivially sleep, and GUP calls it under
the PTE lock. So how can we replace that? Would callers need to manually dirty
folios after GUP, in process context?

-- 
Pedro