Re: [PATCH v4 01/11] iomap: introduce IOMAP_F_ZERO_TAIL flag
From: Darrick J. Wong
Date: Mon May 18 2026 - 12:09:39 EST
On Mon, May 18, 2026 at 08:46:55PM +0900, Namjae Jeon wrote:
> 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.
>
> Acked-by: Christoph Hellwig <hch@xxxxxx>
> Signed-off-by: Namjae Jeon <linkinjeon@xxxxxxxxxx>
AFAICT, the "valid size" means "all space between valid_size and i_size
is unwritten", and that's why you need the tail of the block to be
zeroed, right?
So if, say, the fsblock size is 4k and valid_size is 80k; and I initiate
a pwrite of 300 bytes at 121k, exfat will do its own zeroing to bump
valid_size up to 121k, right? Then the actual iomap_write call will
copy the 300 bytes into the pagecache, and now it needs ZERO_TAIL to
zero the rest of the pagecache from (121k + 300) to 124k, correct?
(What I'm probing for is, there's no need for a ZERO_HEAD at this time
because exfat has to take care of that, right?)
Reviewed-by: "Darrick J. Wong" <djwong@xxxxxxxxxx>
--D
> ---
> 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..44046c648df4 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -836,6 +836,7 @@ static int __iomap_write_begin(const struct iomap_iter *iter,
> return -EIO;
> folio_zero_segments(folio, poff, from, to, poff + plen);
> } else {
> + const struct iomap *iomap = iomap_iter_srcmap(iter);
> int status;
>
> if (iter->flags & IOMAP_NOWAIT)
> @@ -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..750602e18750 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 the remainder of the block after the data
> + * written 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
>