From: Yuezhang Mo <Yuezhang.Mo@sony.com>
To: exfat@lists.linux.dev
Cc: linux-kernel@vger.kernel.org, linkinjeon@kernel.org,
sj1557.seo@samsung.com, chizhiling@163.com, dxdt@dev.snart.me,
Yuezhang Mo <Yuezhang.Mo@sony.com>
Subject: [PATCH v3] exfat: mark straddling folio RO and zero the post-EOF range
Date: Sat, 10 Oct 2026 18:12:01 +0800 [thread overview]
Message-ID: <20261010101200.1211462-2-Yuezhang.Mo@sony.com> (raw)
When extending a file across a non-page-aligned EOF, the folio
containing the old EOF must be marked RO so that subsequent mmap
writes trigger ->page_mkwrite() and update valid_size.
The straddling folio remains mapped to the same filesystem block
after the file is extended. As a result, the existing writable PTE
may remain in place, allowing mmap writes to bypass ->page_mkwrite()
and leave valid_size unchanged.
Furthermore, writes to the post-EOF range may occur between
truncate_pagecache() and locking the folio. So the post-EOF range
should be zeroed after marking the straddling folio RO, and using
truncate_pagecache() to zero out the post-EOF range is redundant.
Introduce exfat_pagecache_isize_extended() to mark the straddling
folio RO and zero the post-EOF range after clearing writable mapping.
This ensures that data written beyond the old EOF before the extension
is not exposed as valid file data, and that subsequent mmap writes
trigger ->page_mkwrite() to update valid_size.
Fixes: 82a81a7352bc ("exfat: add iomap buffered I/O support")
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
---
v2: https://lore.kernel.org/all/20261009093020.1018892-3-Yuezhang.Mo@sony.com/
v1: https://lore.kernel.org/all/20260930104332.4022207-2-Yuezhang.Mo@sony.com/
fs/exfat/file.c | 65 ++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 56 insertions(+), 9 deletions(-)
diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index d24f0650bfc88..9af3de65e2267 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -17,11 +17,63 @@
#include <linux/fileattr.h>
#include <linux/iomap.h>
#include <linux/pagemap.h>
+#include <linux/rmap.h>
#include "exfat_raw.h"
#include "exfat_fs.h"
#include "iomap.h"
+/*
+ * Unlike pagecache_isize_extended(), this function updates i_size while
+ * holding the straddling folio lock, and does not skip the straddling
+ * folio when the filesystem block size is >= PAGE_SIZE or when 'from'
+ * and 'to' fall within the same filesystem block.
+ *
+ * This ensures that the folio is marked RO and the post-EOF range is
+ * zeroed before writeback can observe the updated i_size.
+ */
+static void exfat_pagecache_isize_extended(struct inode *inode, loff_t from,
+ loff_t to)
+{
+ struct folio *folio;
+
+ if (!(from & (PAGE_SIZE - 1))) {
+ i_size_write(inode, to);
+ return;
+ }
+
+ folio = filemap_lock_folio(inode->i_mapping, from >> PAGE_SHIFT);
+ i_size_write(inode, to);
+
+ /* Folio not cached? Nothing to do */
+ if (IS_ERR(folio))
+ return;
+
+ /*
+ * See folio_clear_dirty_for_io() for details why folio_mark_dirty()
+ * is needed.
+ */
+ if (folio_mkclean(folio))
+ folio_mark_dirty(folio);
+
+ /*
+ * The post-eof range of the folio must be zeroed before it is exposed
+ * to the file. Writeback normally does this, but since i_size has been
+ * increased we handle it here.
+ */
+ if (folio_test_dirty(folio)) {
+ loff_t offset, end;
+
+ offset = from - folio_pos(folio);
+ end = min_t(loff_t, to - folio_pos(folio),
+ folio_size(folio));
+ folio_zero_segment(folio, offset, end);
+ }
+
+ folio_unlock(folio);
+ folio_put(folio);
+}
+
static int exfat_cont_expand(struct inode *inode, loff_t size)
{
int ret;
@@ -32,8 +84,6 @@ static int exfat_cont_expand(struct inode *inode, loff_t size)
struct exfat_chain clu;
loff_t oldsize = i_size_read(inode);
- truncate_pagecache(inode, oldsize);
-
ret = inode_newsize_ok(inode, size);
if (ret)
return ret;
@@ -81,15 +131,12 @@ static int exfat_cont_expand(struct inode *inode, loff_t size)
out:
inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode));
- /* Expanded range not zeroed, do not update valid_size */
- i_size_write(inode, size);
/*
- * When extending file size, call truncate_pagecache() first,
- * then update i_size, and call pagecache_isize_extended()
- * to ensures the straddling folio is properly marked RO so
- * page_mkwrite() is called and post-EOF area is zeroed.
+ * When extending file size, call exfat_pagecache_isize_extended()
+ * to updates i_size and ensures the straddling folio is properly
+ * marked RO so page_mkwrite() is called and post-EOF area is zeroed.
*/
- pagecache_isize_extended(inode, oldsize, inode->i_size);
+ exfat_pagecache_isize_extended(inode, oldsize, size);
inode->i_blocks = round_up(size, sbi->cluster_size) >> 9;
mark_inode_dirty(inode);
--
2.43.0
reply other threads:[~2026-10-10 10:12 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=20261010101200.1211462-2-Yuezhang.Mo@sony.com \
--to=yuezhang.mo@sony.com \
--cc=chizhiling@163.com \
--cc=dxdt@dev.snart.me \
--cc=exfat@lists.linux.dev \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sj1557.seo@samsung.com \
/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
all inboxes | Powered by JetHome®