Re: [PATCH v3 06/35] fsverity: pass digest size and hash of the empty block to ->write

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Feb 19, 2026 at 06:58:57AM +0100, Christoph Hellwig wrote:
> On Wed, Feb 18, 2026 at 01:17:52PM +0100, Andrey Albershteyn wrote:
> > On 2026-02-18 07:18:34, Christoph Hellwig wrote:
> > > On Wed, Feb 18, 2026 at 12:19:06AM +0100, Andrey Albershteyn wrote:
> > > > Let filesystem iterate over hashes in the block and check if these are
> > > > hashes of zeroed data blocks. XFS will use this to decide if it want to
> > > > store tree block full of these hashes.
> > > 
> > > Does it make sense to pass in the zero_digest vs just having a global
> > > symbol or accessor?  This should be static information.
> > 
> > I think this won't work if we have two filesystems with different
> > block sizes and therefore different merkle block sizes => different
> > hash.
> 
> Looking at this a bit more - you're storing the entirely zero_digest
> in struct merkle_tree_params, which is embedded intothe
> fsverity_info.  This means that you can trivially access it using an
> accessor of the fsverity_inode.

Not in ->write_merkle_tree_block(), since that's called during
FS_IOC_ENABLE_VERITY before the fsverity_info has been set.

> It also means that you actually bloat that structure quite a bit for
> constant file system wide information.  Maybe it's time to split
> out the file system wide part of it into a separate structure?

The hash of a block of zeroes depends on the salt, which is a per-file
value.  The salt is optional, though.

There is already another dynamic allocation done only for files that use
a salt: merkle_tree_params::hashstate.

The hash could be stored in that same allocation for salted files, or as
a fixed value in struct fsverity_hash_alg for unsalted files.  Then at
least unsalted files wouldn't use any additional memory per-file.

- Eric