Re: [PATCH 2/7] fuse: Use filemap_invalidate_pages()

On Mon, Aug 24, 2026 at 09:33:03PM +0200, Miklos Szeredi wrote:
> On Mon, 24 Aug 2026 at 20:17, Matthew Wilcox <[email protected]> wrote:
> 
> > Before:
> >
> > fuse_open()
> >         invalidate_inode_pages2()
> >                 folio_lock()
> >                 folio_unmap_invalidate()
> >                         folio_launder()
> >                 folio_unlock()
> >
> > After:
> >
> > fuse_open()
> >         filemap_invalidate_pages()
> >                 filemap_write_and_wait_range()
> >                 invalidate_inode_pages2_range()
> >                         folio_lock()
> >                         folio_unmap_invalidate()
> >                                 folio_test_dirty()
> >                         folio_unlock()
> >
> > so what's the serialisation that the filesystem can perform in the first
> > case that it can't perform in the second case?
> 
> In the second case filemap_write_and_wait_range() won't write protect
> or unmap the page, so it may become dirty after the writeback.

But that can also happen in the first case.  page_mkwrite() can be called
immediately after the folio is unlocked, for example.  Or the folio can
be evicted and replaced with a different folio which is then dirtied.

I've widened the race window, no doubt.  But it was always there.
If you want to prevent something like that from happening, you need
to be holding the invalidate_lock across the call to
filemap_invalidate_folio() and whatever other thing you're doing that
needs those pages clean.

> That can't happen in the first case, since the page is written and
> unmapped while under page lock.
> 
> > or alternatively, what's the serialisation that would be useful by
> > adding a lock/unlock of the invalidate_lock inside
> > filemap_invalidate_pages()?
> 
> Nothing.
> 
> What would prevent this if we'd have writeback + unmap + writeback.

We could do that -- but it won't solve the problem because the pages
could still be redirtied after the second writeback.