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 > >
