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

[Christoph Hellwig <hch@lst.de>]

On Wed, Feb 18, 2026 at 10:41:14AM +0100, Andrey Albershteyn wrote:
> > +		 * 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.
> > +		 *
> > +		 *	No ctx->vi means we are reading a folio with descriptor.
> > +		 *	XXX: what does descriptor mean here?  Also how do we
> > +		 *	even end up with this case?  I can't see how this can
> > +		 *	happe based on the caller?
> 
> 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?

> I think this could be split into two cases by checking if (poff +
> plen) cover everything to the folio end. This means that we didn't
> get the case with tree holes and descriptor in one folio.

That might be more clear.

> > +		    	if (!ctx->vi) {
> > +				iomap_set_range_uptodate(folio, poff, plen);
> > +				/*
> > +				 * XXX: why return to the caller early here?
> > +				 */
> 
> To not hit hole in the tree (which means synthesize the block). The
> fsverity_folio_zero_hash() case.

Well, I mean return early from the function and not just move on
to the next loop iteration (which based on everything else you
wrote would then terminate anyway), і.e., why is this not:

		if (!ctx->vi)
			fsverity_folio_zero_hash(folio, poff, plen, ctx->vi)
		iomap_set_range_uptodate(folio, poff, plen);
	} else if ...

?