From: Matthew Wilcox <willy@infradead.org>
To: linux-fsdevel@vger.kernel.org
Cc: fstests@vger.kernel.org
Subject: [RFC] pagecache_isize_extended
Date: Wed, 17 Jan 2024 16:16:14 +0000 [thread overview]
Message-ID: <Zaf9TgExOXsOYvW4@casper.infradead.org> (raw)
I hadn't looked at pagecache_isize_extended() before, and I'm not
entirely sure it's doing the right thing for large folios. Usually
we decline to create folios which extend past EOF [1], and we try to split
folios on truncate. But folio splitting can fail, and I think we might
run into problems with a store to a folio which straddles i_size.
Do we have any xfstests which cover this? I'm not quite sure how to
write such a test.
[1] or at least EOF rounded up to PAGE_SIZE
diff --git a/mm/truncate.c b/mm/truncate.c
index 725b150e47ac..3025c579db52 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -781,8 +781,7 @@ void pagecache_isize_extended(struct inode *inode, loff_t from, loff_t to)
{
int bsize = i_blocksize(inode);
loff_t rounded_from;
- struct page *page;
- pgoff_t index;
+ struct folio *folio;
WARN_ON(to > inode->i_size);
@@ -793,19 +792,18 @@ void pagecache_isize_extended(struct inode *inode, loff_t from, loff_t to)
if (to <= rounded_from || !(rounded_from & (PAGE_SIZE - 1)))
return;
- index = from >> PAGE_SHIFT;
- page = find_lock_page(inode->i_mapping, index);
- /* Page not cached? Nothing to do */
- if (!page)
+ folio = filemap_lock_folio(inode->i_mapping, from / PAGE_SIZE);
+ /* Folio not cached? Nothing to do */
+ if (!folio)
return;
/*
- * See clear_page_dirty_for_io() for details why set_page_dirty()
+ * See folio_clear_dirty_for_io() for details why folio_mark_dirty()
* is needed.
*/
- if (page_mkclean(page))
- set_page_dirty(page);
- unlock_page(page);
- put_page(page);
+ if (folio_mkclean(folio))
+ folio_mark_dirty(folio);
+ folio_unlock(folio);
+ folio_put(folio);
}
EXPORT_SYMBOL(pagecache_isize_extended);
reply other threads:[~2024-01-17 16:16 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zaf9TgExOXsOYvW4@casper.infradead.org \
--to=willy@infradead.org \
--cc=fstests@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox