Re: [PATCH v3 28/35] xfs: add fs-verity support

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Feb 19, 2026 at 03:38:57PM +0100, Andrey Albershteyn wrote:
> On 2026-02-19 14:41:01, Christoph Hellwig wrote:
> > On Thu, Feb 19, 2026 at 10:51:14AM +0100, Andrey Albershteyn wrote:
> > > > > fs block size < PAGE_SIZE when these tree holes are in one folio
> > > > > with descriptor. Iomap can not fill them without getting descriptor
> > > > > first.
> > > > 
> > > > Should we just simply not create tree holes for that case?  Anything
> > > > involving page cache validation is a pain, so if we have an easy
> > > > enough way to avoid it I'd rather do that.
> > > 
> > > I don't think we can. Any hole at the tree tail which gets into the
> > > same folio with descriptor need to be skipped. If we write out
> > > hashes instead of the holes for the 4k page then other holes at
> > > lower offsets of the tree still can have holes on bigger page
> > > system.
> > 
> > Ok.
> > 
> > > Adding a bit of space between tree tail and descriptor would
> > > probably work but that's also dependent on the page size.
> > 
> > Well, I guess then the only thing we can do is writes very detailed
> > comments explaining all this.
> > 
> 
> I have a comment right above this function:
> 
> +/*
> + * In cases when merkle tree block (1k) == fs block size (1k) and less than
> + * PAGE_SIZE (4k) we can get the following layout in the file:
> + *
> + * [ merkle block | 1k hole | 1k hole | fsverity descriptor]
> + *
> + * These holes are merkle tree blocks which are filled by iomap with hashes of
> + * zeroed data blocks.
> + *
> + * Anything in fsverity starts with reading a descriptor. When iomap reads this
> + * page for the descriptor it doesn't know how to synthesize those merkle tree
> + * blocks. So, those are left with random data and marked uptodate.
> + *
> + * After we're done with reading the descriptor we invalidate the page
> + * containing descriptor. As a descriptor for this inode is already searchable
> + * in the hashtable, iomap can synthesize these blocks when requested again.
> + */
> +static int
> +xfs_fsverity_drop_descriptor_page(
> +	struct inode	*inode,
> +	u64		offset)
> 
> I will rephrase the first sentence to make it clear that this could
> happen for larger page sizes too.

I wonder if you could rearrange the layout to put the fsverity
descriptor first and start the merkle tree at the next
fsverity-blocksize-aligned offset past the descriptor?  Then you
wouldn't have to care with a sparse tail.

OTOH it's been so long since I fiddled with fsverity that I don't
remember if there's a Much Better Reason not to do that. <shrug>

--D


> -- 
> - Andrey
> 
>