From: Namjae Jeon <linkinjeon@kernel.org>
To: sj1557.seo@samsung.com, yuezhang.mo@sony.com, brauner@kernel.org,
djwong@kernel.org, hch@lst.de
Cc: linux-fsdevel@vger.kernel.org, anmuxixixi@gmail.com,
dxdt@dev.snart.me, chizhiling@kylinos.cn,
linux-kernel@vger.kernel.org, Namjae Jeon <linkinjeon@kernel.org>
Subject: [PATCH v2 5/9] iomap: introduce IOMAP_F_ZERO_TAIL flag
Date: Thu, 7 May 2026 21:42:34 +0900 [thread overview]
Message-ID: <20260507124238.7313-6-linkinjeon@kernel.org> (raw)
In-Reply-To: <20260507124238.7313-1-linkinjeon@kernel.org>
In filesystems that maintain a separate Valid Data Length, such as exFAT
and NTFS, a partial write may start at or beyond the current valid_size and
extend it. In this case, the region after the previous valid_size but
within the same filesystem block is considered unwritten.
This patch introduces IOMAP_F_ZERO_TAIL. When this flag is set in iomap,
__iomap_write_begin() will zero only the tail portion while preserving any
valid data before it in the same block.
Without this tail zeroing, stale data in the unwritten portion of the block
can remain in the page cache. Subsequent reads can then return incorrect
contents from that region.
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
---
fs/iomap/buffered-io.c | 4 ++++
include/linux/iomap.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index d7b648421a70..9ae136a9fcd4 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -837,6 +837,7 @@ static int __iomap_write_begin(const struct iomap_iter *iter,
folio_zero_segments(folio, poff, from, to, poff + plen);
} else {
int status;
+ const struct iomap *iomap = iomap_iter_srcmap(iter);
if (iter->flags & IOMAP_NOWAIT)
return -EAGAIN;
@@ -853,6 +854,9 @@ static int __iomap_write_begin(const struct iomap_iter *iter,
len, status, GFP_NOFS);
if (status)
return status;
+
+ if (iomap->flags & IOMAP_F_ZERO_TAIL)
+ folio_zero_segment(folio, to, poff + plen);
}
iomap_set_range_uptodate(folio, poff, plen);
} while ((block_start += plen) < block_end);
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
index 2c5685adf3a9..e3e7ad72b29e 100644
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@ -67,6 +67,9 @@ struct vm_fault;
* bio, i.e. set REQ_ATOMIC.
*
* IOMAP_F_INTEGRITY indicates that the filesystems handles integrity metadata.
+ *
+ * IOMAP_F_ZERO_TAIL indicates only the unwritten tail of the block should be
+ * zeroed.
*/
#define IOMAP_F_NEW (1U << 0)
#define IOMAP_F_DIRTY (1U << 1)
@@ -86,6 +89,7 @@ struct vm_fault;
#else
#define IOMAP_F_INTEGRITY 0
#endif /* CONFIG_BLK_DEV_INTEGRITY */
+#define IOMAP_F_ZERO_TAIL (1U << 10)
/*
* Flag reserved for file system specific usage
--
2.25.1
next prev parent reply other threads:[~2026-05-07 12:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 12:42 [PATCH v2 0/9] exfat: convert to iomap Namjae Jeon
2026-05-07 12:42 ` [PATCH v2 1/9] exfat: replace unsafe macros with static inline functions Namjae Jeon
2026-05-07 13:41 ` CharSyam
2026-05-07 23:36 ` Namjae Jeon
2026-05-07 12:42 ` [PATCH v2 2/9] exfat: add balloc parameter to exfat_map_cluster() for iomap support Namjae Jeon
2026-05-07 12:42 ` [PATCH v2 3/9] exfat: add exfat_file_open() Namjae Jeon
2026-05-07 13:52 ` CharSyam
2026-05-07 23:37 ` Namjae Jeon
2026-05-07 12:42 ` [PATCH v2 4/9] exfat: add support for multi-cluster allocation Namjae Jeon
2026-05-07 14:09 ` CharSyam
2026-05-08 0:27 ` Namjae Jeon
2026-05-10 13:32 ` Chi Zhiling
2026-05-11 0:20 ` Namjae Jeon
2026-05-11 0:45 ` Chi Zhiling
2026-05-07 12:42 ` Namjae Jeon [this message]
2026-05-09 9:59 ` [PATCH v2 5/9] iomap: introduce IOMAP_F_ZERO_TAIL flag Chi Zhiling
2026-05-09 14:30 ` Namjae Jeon
2026-05-07 12:42 ` [PATCH v2 6/9] exfat: add data_start_bytes and exfat_cluster_to_phys() helper Namjae Jeon
2026-05-07 12:42 ` [PATCH v2 7/9] exfat: add iomap buffered I/O support Namjae Jeon
2026-05-07 12:42 ` [PATCH v2 8/9] exfat: add iomap direct " Namjae Jeon
2026-05-07 12:42 ` [PATCH v2 9/9] exfat: add support for SEEK_HOLE and SEEK_DATA in llseek Namjae Jeon
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=20260507124238.7313-6-linkinjeon@kernel.org \
--to=linkinjeon@kernel.org \
--cc=anmuxixixi@gmail.com \
--cc=brauner@kernel.org \
--cc=chizhiling@kylinos.cn \
--cc=djwong@kernel.org \
--cc=dxdt@dev.snart.me \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sj1557.seo@samsung.com \
--cc=yuezhang.mo@sony.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