Re: [PATCH v13 02/23] fsverity: expose ensure_fsverity_info()

On Tue, Jul 21, 2026 at 08:40:39PM +0200, Andrey Albershteyn wrote:
> +/**
> + * fsverity_ensure_verity_info() - cache verity info if it's not already cached
> + * @inode: the inode for which verity info should be cached
> + *
> + * Ensure this inode has verity info attached to it, it's assumed the inode
> + * already has fsverity enabled. Read fsverity descriptor and creates verity
> + * based on that.
> + *
> + * This needs to be called at least once before any of the inode's data
> + * can be verified (and thus read at all) or the inode's fsverity digest
> + * retrieved.  fsverity_file_open() calls this already, which handles
> + * normal file accesses.  If a filesystem does any internal (i.e. not
> + * associated with a file descriptor) reads of the file's data or
> + * fsverity digest, it must call this explicitly before doing so.
> + *
> + * Return: 0 on success, -errno on failure
> + */
> +int fsverity_ensure_verity_info(struct inode *inode)

There really should be a note here that if the file is also encrypted,
then the encryption key has to have been set up first.  This was already
gotten wrong when it was proposed for overlayfs to call this.

Do we also need a more specific contract than "-errno on failure"?  The
caller in xchk_inode_setup_verity() tries to distinguish between
"metadata validation errors" and "runtime errors" by checking for a
bunch of different error codes, and I'm not sure what that means
exactly.

- Eric