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 03:23:11PM +0100, Andrey Albershteyn wrote:
> On 2026-02-19 14:38:29, Christoph Hellwig wrote:
> > 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?
> 
> I mean that to have ctx->vi we need to read fsverity descriptor
> first. When iomap is reading fsverity descriptor inode won't have
> any fsverity_info yet.

So for ext4/f2fs the pattern is that it is set by:

	if (folio->index < DIV_ROUND_UP(inode->i_size, PAGE_SIZE))
		vi = fsverity_get_info(inode);

i.e., only for reading the data.  OTOH, for iomap we do:

	if (fsverity_active(iter.inode)) {
		ctx->vi = fsverity_get_info(iter.inode);

which means it now is set for all I/O on fsverity files, which
is subtly different.

(You don't actually need the fsverity_active chck, fsverity_get_info
already does that, btw).

I'm still not sure what "When iomap is reading fsverity descriptor
inode" means.

> > 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.
> 
> Don't you confused this with fsverity_get_info()? I don't see how it
> could cause lookup.

Yeah.  Still, having ctx->vi implies fsverity_active, and follows
what we're doing elsewhere.

> 
> > 
> > Please document the rules for ctx->vi while were it.
> > 
> 
> Hmm, the vi is set in iomap_read_folio() [1] and then used down
> through I/O up to ioend completion. What info you would like to see
> there?

See above, unlike ext4/f2fs we set it for all I/O on fsverity inodes.
And afaik we don't actually need it, the only use in the fsverity
metadata path is the fill zeroes hash values check (which I'm still
totally confused about).