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

On Mon, Aug 24, 2026 at 03:49:37PM +0200, Miklos Szeredi wrote:
> On Mon, 24 Aug 2026 at 15:29, Matthew Wilcox <[email protected]> wrote:
> >
> > On Mon, Aug 24, 2026 at 11:05:46AM +0200, Miklos Szeredi wrote:
> 
> > > Maybe add a variant that takes that lock?
> >
> > I don't understand what use that would be.  As soon as that function
> > drops the lock, the pages could be reinstated.  If the caller needs the
> > pages to not come back, it must need to hold the invalidate_lock across
> > the whole operation.
> 
> invalidate_inode_pages2_range() together with launder_page guaranteed
> that no dirty data remained in the cache after that call.   Yes, the
> pages can be reinstated after that but those need faults and the
> server can then serialize those against the invalidation.
> 
> I don't see that guarantee with the filemap_write_and_wait_range()
> (with or without invalidate_lock actually) since the mapping can be
> dirtied again without the filesystem's knowledge.
> 
> Am I missing something?

Well, one of us is!

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?

or alternatively, what's the serialisation that would be useful by
adding a lock/unlock of the invalidate_lock inside
filemap_invalidate_pages()?