Re: [PATCH v3 11/35] iomap: allow filesystem to read fsverity metadata beyound EOF

[Christoph Hellwig <hch@lst.de>]

On Thu, Feb 19, 2026 at 12:11:18PM +0100, Andrey Albershteyn wrote:
> > > fsverity descriptor. This is basically the case as for EOF folio.
> > > Descriptor is the end of the fsverity metadata region. If we have 1k
> > > fs blocks (= merkle blocks) we can have [descriptor | hole ] folio.
> > > As we are not limited by i_size here, iomap_block_needs_zeroing()
> > > won't fire to zero this hole. So, this case is to mark this tail as
> > > uptodate.
> > 
> > How do we end up in that without ctx->vi set?
> 
> We're reading it

Did a part of that sentence get lost?

> yes this would work
> 
> I've attached the current patch, with all the changes.
> 
> +               } else if (iomap_block_needs_zeroing(iter, pos) &&
> +                          !(iomap->flags & IOMAP_F_FSVERITY)) {
> 
> This check is still needed as we should not hit it when we're
> reading normal merkle tree block. iomap_block_needs_zeroing is
> checking if offset is beyond i_size and will fire here for merkle
> blocks.
> 
> Let me know if you prefer to split the first case further, or the
> current patch is good enough.
> 
> -- 
> - Andrey
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 47356c763744..af7b79073879 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -533,10 +533,31 @@ static int iomap_read_folio_iter(struct iomap_iter *iter,
>                 if (plen == 0)
>                         return 0;
>  
> -               /* zero post-eof blocks as the page may be mapped */
> -               if (iomap_block_needs_zeroing(iter, pos) &&
> -                   !(iomap->flags & IOMAP_F_FSVERITY)) {
> +               /*
> +                * Handling of fsverity "holes". We hits this for two case:
> +                *   1. No need to go further, the hole after fsverity
> +                *      descriptor is the end of the fsverity metadata.
> +                *
> +                *   2. This folio contains merkle tree blocks which need to be

Overly long line here.

> +                *      synthesized and fsverity descriptor.
> +                */
> +               if ((iomap->flags & IOMAP_F_FSVERITY) &&
> +                   iomap->type == IOMAP_HOLE) {
> +                       /*
> +                        * Synthesize the hash value for a zeroed folio if we
> +                        * are reading merkle tree blocks.
> +                        */

.. and we'll probably want to merge this into the above comment.

> +                       if (ctx->vi)
> +                               fsverity_folio_zero_hash(folio, poff, plen,
> +                                                        ctx->vi);
> +                       iomap_set_range_uptodate(folio, poff, plen);
> +               } else if (iomap_block_needs_zeroing(iter, pos) &&
> +                          !(iomap->flags & IOMAP_F_FSVERITY)) {
> +                       /* zero post-eof blocks as the page may be mapped */
>                         folio_zero_range(folio, poff, plen);
> +                       if (fsverity_active(iter->inode) &&
> +                           !fsverity_verify_blocks(ctx->vi, folio, plen, poff))

Another overly long line here.  Also we should avoid the
fsverity_active check here, as it causes a rhashtable lookup.  F2fs
and ext4 just check ctx->vi, but based on the checks above, we seem
to set this also for (some) reads of the fsverity metadata.  But as
we exclude IOMAP_F_FSVERITY above, we might actually be fine with a
ctx->vi anyway.

Please document the rules for ctx->vi while were it.