Skip to content

Remove aops->launder_folio - #1163

Open
blktests-ci[bot] wants to merge 7 commits into
linus-master_basefrom
series/1149291=>linus-master
Open

Remove aops->launder_folio#1163
blktests-ci[bot] wants to merge 7 commits into
linus-master_basefrom
series/1149291=>linus-master

Conversation

@blktests-ci

@blktests-ci blktests-ci Bot commented Aug 20, 2026

Copy link
Copy Markdown

Pull request for series with
subject: Remove aops->launder_folio
version: 1
url: https://patchwork.kernel.org/project/linux-block/list/?series=1149291

Matthew Wilcox (Oracle) added 7 commits August 20, 2026 20:02
This is a better API for filesystems to use than
invalidate_inode_pages2() / invalidate_inode_pages2_range().
However, the 'nowait' argument is unnecessary for them.  It's also
wrongly implemented as it will call invalidate_inode_pages2_range()
even after filemap_range_has_page() returns false.

Move the filemap_range_has_page() call into the two existing callers
and add kernel-doc.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
FUSE relies on invalidate_inode_pages2() / invalidate_inode_pages2_range()
doing writeback by calling fuse_launder_folio().  While this works, it
is inefficient as each page is written back and waited for individually.
Far better to call filemap_invalidate_pages() which will do a bulk write
first, then remove the page cache.

With this done, fuse_launder_folio() no longer needs to exist so
delete it.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
btrfs relies on invalidate_inode_pages2() /
invalidate_inode_pages2_range() doing writeback by calling
btrfs_launder_folio().  While this works, it is inefficient as each
folio is written back and waited for individually.  Far better to call
filemap_invalidate_pages() which will do a bulk write first, then remove
the page cache.

With this done, btrfs_launder_folio() no longer needs to exist so
delete it.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
nfs relies on invalidate_inode_pages2() / invalidate_inode_pages2_range()
doing writeback by calling nfs_launder_folio().  While this works, it is
inefficient as each folio is written back and waited for individually.
Far better to call filemap_invalidate_pages() which will do a bulk write
first, then remove the page cache.

With this done, nfs_launder_folio() no longer needs to exist so delete it.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
This pair of calls simply open-codes Use filemap_invalidate_pages(),
so convert it.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
There doesn't seem to be a good reason to implement ->launder_folio
in orangefs.  Leave orangefs_launder_folio() alone as it is used
in several places and removing it entirely would be tricky.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
When we do direct I/O, we need to evict any page cache that overlaps
the range in the file.  First we write back any dirty folios in the
range, then we lock each folio and remove it from the CPU page tables.
This leaves a wide window for userspace to re-dirty the folio by storing
to a shared writable mmap.

Many filesystems respond to this situation by failing the call to
release_folio(), but some try to writeback the dirty folio again, formerly
in their release_folio() method and now in their launder_folio() method.

Remove this inconsistency between filesystems by checking
whether the folio is dirty in the VFS and failing the call to
folio_unmap_invalidate().  Since we hold the folio locked and unmapped
at this time, there is no way to dirty the folio after this point.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
@blktests-ci

blktests-ci Bot commented Aug 20, 2026

Copy link
Copy Markdown
Author

Upstream branch: bd5f485
series: https://patchwork.kernel.org/project/linux-block/list/?series=1149291
version: 1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants