Re: [PATCH RFC 02/29] iomap: introduce iomap_read/write_region interface

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Sep 09, 2025 at 02:30:14PM +0200, Andrey Albershteyn wrote:
> On 2025-08-11 13:43:37, Christoph Hellwig wrote:
> > On Tue, Jul 29, 2025 at 03:22:52PM -0700, Darrick J. Wong wrote:
> > > ...and these sound a lot like filemap_read and iomap_write_iter.
> > > Why not use those?  You'd get readahead for free.  Though I guess
> > > filemap_read cuts off at i_size so maybe that's why this is necessary?
> > > 
> > > (and by extension, is this why the existing fsverity implementations
> > > seem to do their own readahead and reading?)
> > > 
> > > ((and now I guess I see why this isn't done through the regular kiocb
> > > interface, because then we'd be exposing post-EOF data hiding to
> > > everyone in the system))
> > 
> > Same thoughts here.  It seems like we should just have a beyond-EOF or
> > fsverity flag for ->read_iter / ->write_iter and consolidate all this
> > code.  That'll also go along nicely with the flag in the writepage_ctx
> > suggested by Joanne.
> > 
> 
> In addition to being bound by the isize the fiemap_read() copies
> data to the iov_iter, which is not really needed for fsverity. Also,
> even on fsverity systems this function will not be called on the
> fsverity metadata, not sure how much overhead these checks would add
> but this is probably not desired anyway.
> 
> Is adding something like fiemap_fetch or fiemap_read_unbound to just
> call filemap_get_pages() would be better? A filemap_read() without
> isize check and copying basically

TBH I've started wondering if what fsverity wants is filemap_fault(),
but with a special flag that enables faults beyond EOF.  After all, it
creates a folio, reads the data from disk, and returns a locked folio.

> The write path seems to be fine, adding kiocb->ki_flags and
> iomap_iter->flags flag to work beyond EOF to skip inode size updates
> in iomap_write_iter() seems to be enough.

<nod>

--D

> -- 
> - Andrey
> 
>