Re: [PATCH v2 3/22] iomap: introduce IOMAP_F_BEYOND_EOF

[Christoph Hellwig <hch@lst.de>]

On Mon, Jan 12, 2026 at 02:18:53PM -0800, Darrick J. Wong wrote:
> On Mon, Jan 12, 2026 at 03:50:05PM +0100, Andrey Albershteyn wrote:
> > Flag to indicate to iomap that read/write is happening beyond EOF and no
> > isize checks/update is needed.
> > 
> > Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>
> > ---
> >  fs/iomap/buffered-io.c | 13 ++++++++-----
> >  fs/iomap/trace.h       |  3 ++-
> >  include/linux/iomap.h  |  5 +++++
> >  3 files changed, 15 insertions(+), 6 deletions(-)
> > 
> > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> > index e5c1ca440d..cc1cbf2a4c 100644
> > --- a/fs/iomap/buffered-io.c
> > +++ b/fs/iomap/buffered-io.c
> > @@ -533,7 +533,8 @@
> 
> (Does your diff program not set --show-c-function?  That makes reviewing
> harder because I have to search on the comment text to figure out which
> function this is)

Or use git-send-email which sidesteps all these issues :)

> Hrm.  The last test in iomap_block_needs_zeroing is if pos is at or
> beyond EOF, and iomap_adjust_read_range takes great pains to reduce plen
> so that poff/plen never cross EOF.  I think the intent of that code is
> to ensure that we always zero the post-EOF part of a folio when reading
> it in from disk.
> 
> For verity I can see why you don't want to zero the merkle tree blocks
> beyond EOF, but I think this code can expose unwritten junk in the
> post-EOF part of the EOF block on disk.
> 
> Would it be more correct to do:

Or replace the generic past EOF flag with a FSVERITY flag making
the use case clear?

> > @@ -1815,8 +1817,9 @@
> >  
> >  	trace_iomap_writeback_folio(inode, pos, folio_size(folio));
> >  
> > -	if (!iomap_writeback_handle_eof(folio, inode, &end_pos))
> > -		return 0;
> > +	if (!(wpc->iomap.flags & IOMAP_F_BEYOND_EOF) &&
> > +	    !iomap_writeback_handle_eof(folio, inode, &end_pos))
> 
> Hrm.  I /think/ this might break post-eof zeroing on writeback if
> BEYOND_EOF is set.  For verity this isn't a problem because there's no
> writeback, but it's a bit of a logic bomb if someone ever tries to set
> BEYOND_EOF on a non-verity file.

Maybe we should not even support the flag for writeback?