linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/1] Is pagecache_isize_extended() compatible with large folios?
@ 2024-02-28 18:22 Matthew Wilcox (Oracle)
  2024-02-28 18:22 ` [PATCH 1/1] mm: Convert pagecache_isize_extended to use a folio Matthew Wilcox (Oracle)
  0 siblings, 1 reply; 3+ messages in thread
From: Matthew Wilcox (Oracle) @ 2024-02-28 18:22 UTC (permalink / raw)
  To: linux-fsdevel, linux-mm; +Cc: Matthew Wilcox (Oracle)

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-02-29 15:43 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-28 18:22 [PATCH 0/1] Is pagecache_isize_extended() compatible with large folios? Matthew Wilcox (Oracle)
2024-02-28 18:22 ` [PATCH 1/1] mm: Convert pagecache_isize_extended to use a folio Matthew Wilcox (Oracle)
2024-02-29 15:43   ` Pankaj Raghav (Samsung)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox