[PATCH 0/1] Is pagecache_isize_extended() compatible with large folios?

["Matthew Wilcox (Oracle)" <willy@infradead.org>]

I'd appreciate some filesystem people checking my work here (in that
pagecache_isize_extended() may already be broken and we didn't notice).

As far as I can tell (and it'd be nice to explain this in the kernel-doc
a little more thoroughly), the reason pagecache_isize_extended() exists
is that some filesystems rely on getting page_mkwrite() calls in order to
instantiate blocks.  So if you have a filesystem using 512 byte blocks and
a 256 byte file mmaped, a store anywhere in the page will only result in
block 0 of the file being instantiated and the folio will now be marked
as dirty.

If we ftruncate the file to 2500 bytes before the folio gets written back,
then store to offset 2000, the filesystem will not be notified, so it
will not instantiate a block to store that information in.  Therefore if
we truncate a file up, we need to mark the PTE that straddles the EOF
as read-only so that page_mkwrite() is called.

Now, I think this patch is safe because it's PAGE_SIZE that's important,
not the size of the folio.  We mmap files on PAGE_SIZE boundaries and
we're only asking if there could be a new store which causes a block
to be instantiated.  If the block size is >= PAGE_SIZE, there can't be.
If the folio size happens to be larger than PAGE_SIZE, it doesn't matter.
All that matters is that we protect the folio which crosses i_size if
block size < PAGE_SIZE.

Matthew Wilcox (Oracle) (1):
  mm: Convert pagecache_isize_extended to use a folio

 mm/truncate.c | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

-- 
2.43.0