Re: Removing ->dirty_folio

Re: Removing ->dirty_folio

[Christoph Hellwig]

[adding rdma/hmm folks]

On Tue, Aug 25, 2026 at 08:54:25PM +0100, Matthew Wilcox wrote:
> On Tue, Aug 25, 2026 at 09:35:57PM +0200, Jann Horn 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.
> > 
> > We currently have get_user_pages*() and pin_user_pages*(), where only
> > the pin_*() version is properly usable for write access, right? And
> > dropping such pins should always go through unpin_*() helpers?
> 
> Right.  I'm stuffing cheese into my ears and pretending that people
> aren't calling get_user_pages() to do write accesses.  We should be
> able to use this work to flush out the last remaining ones -- we
> can put in various assertions that folios should still be dirty where
> we currently have folio_mark_dirty() calls.

Last time I checked quite a few places still did.  Including various
network file system O_DIRECT implementations (some got fixed, and
for NFS a series is outstanding) and some really odd looking networking
code.

I wish we could somehow force them to stop doing that, but I can't
think of any. 

> Yes.  I think the only alternative would be storing a checksum of the
> contents of the folio and seeing if it changed since the last write.
> As you say, this is userspace doing something incredibly odd (I really
> don't think people make a habit of mmap()ing files shared writable and
> then giving RDMA longterm write accesses to them.  Not on machines with
> poor quality flash storage anyway).
> 
> Or we could say "these pages only get written back on requested fsync()
> rather than periodically".

Take one step back.  For regular pins we should be able to just wait for
them given that they are by definition short lived, where short lived
is defined by typical I/O latency for a wide range of "typical".
We'll need the right helpers from the MM for that, and make sure
we have a good way to debug file system hangs caused by incorrect
use of the pinning, but all that is a solvable problem.
Splitting read vs write pincounts would be really helpful to reduce
the overhead of that.

The interesting case is FOLL_LONGTERM, as it can pin I/O for a much
longer time.  And that also means IFF the user of FOLL_LONGTERM actually
wants to be able to persist data on a shared mmap, it has to manually
dirty folios one or more times during the FOLL_LONGTERM pin, because
otherwise the file system would never know there is dirty data.
The set_page_dirty call in ib_umem_odp_unmap_dma_pages is an example
for that.

So what we'll need is:

 - a way for the file system to know if a dma pin on a folio is for a
   short-term writable pin vs everything else.
 - for the short term writable pin wait for it for data integrity syncs,
   or otherwise just skip it.
 - for FOLL_LONGTERM users we need an interface to (re-dirty) folios
   while the long term pin persists.  This also needs a way for the
   file system to reserve space.  Either as a rolling / bank switched
   reservation for the whole life time of the mapping (although for
   large mappings this might use up a lot of space), or to do that
   ahead of whatever triggers the dirtying.
   And maybe a way for file systems (or vm ops) to reject long
   term writable pins if they don't want to deal with all this.

Re: Removing ->dirty_folio

[Christoph Hellwig]

On Wed, Aug 26, 2026 at 07:07:33AM +0200, Christoph Hellwig wrote:
> The interesting case is FOLL_LONGTERM, as it can pin I/O for a much
> longer time.  And that also means IFF the user of FOLL_LONGTERM actually
> wants to be able to persist data on a shared mmap, it has to manually
> dirty folios one or more times during the FOLL_LONGTERM pin, because
> otherwise the file system would never know there is dirty data.
> The set_page_dirty call in ib_umem_odp_unmap_dma_pages is an example
> for that.

... not to forget the epic boss of this genre: vmsplice, which is also
still using get_user_pages_fast/FOLL_GET through iov_iter_get_pages2.