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