Re: [PATCH 2/7] fuse: Use filemap_invalidate_pages()
Miklos Szeredi <[email protected]>
| Newsgroups | org.kvack.linux-mm,dev.linux.lists.fuse-devel,org.kernel.vger.linux-block,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-nfs |
|---|---|
| Message-ID | <CAJfpegtgenUaudDcvecJuV2_WkkVw=gdcB0Eqg=UFKPMZP1uKQ@mail.gmail.com> |
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. 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. Thanks, Miklos