Re: Removing ->dirty_folio

[Matthew Wilcox <willy@infradead.org>]

On Tue, Aug 25, 2026 at 09:39:18AM +0200, Christoph Hellwig wrote:
> On Mon, Aug 24, 2026 at 08:08:06PM +0100, Matthew Wilcox wrote:
> > 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.
> 
> We've been through this a few times, I remember me and Jan discussing
> it maybe a year or so on the list last.  This is what I remember:
> 
>  - the best thing would be to just not write folio_maybe_dma_pinned
>    folios at all.  Jan brought up cases where that might not be
>    possible, so we might have to write anyway.  IIRC the major
>    one is that we actually do allow FOLL_LONGTERM even on file
>    backed mappings, and those could be pinned forever.
>  - when we write them anyway we really have to bounce buffer the
>    data.  Basically copy and do something like in-kernel direct I/O
>  - Even that can be tricky, because we'd still need a space reservation
>    for that write at it would otherwise consume the space reservation
>    at dirty time, but we still might have to write it again.  One
>    option might be to only do the force bounce buffer write for
>    FOLL_LONGTERM as the others should go away, and FOLL_LONGTERM
>    gets a call into the fs to reserve extra space.  This would not
>    be enough for a lot of writes, but enough to allow for
>    "bank switching" over GC cycles.
> 
> So, not perfect, but probably better than the status quo.  But a lot
> of work that someone needs to do for being a bit better than the
> status quo.

Thanks for summarising the previous discussion.  I understand what
you're saying about the space reservation; that's why we have to
bring filesystems into the conversation rather than doing it entireely
within the VFS.  They have to know that they must create a new space
reservation immediately after writing back this folio.  That should
be feasible in the writeback path because we're not under any mad
locking scheme like holding the PTL.

I think the only disagreement I have is about the upsides:

 - Filesystems no longer need to implement ->dirty_folio()
 - The page pinning API becomes a bit easier to use (no need to call
   folio_mark_dirty() / folio_mark_dirty_locked())

I'm just trying to figure out if we can do this in small chunks, or
if we have to do the whole thing at once.