Re: [PATCH RFC 12/29] fsverity: expose merkle tree geometry to callers

Andrey Albershteyn
2025-08-11T19:06:09Z

On 2025-08-11 08:38:22, Darrick J. Wong wrote:
> On Mon, Aug 11, 2025 at 01:48:13PM +0200, Christoph Hellwig wrote:
> > On Mon, Jul 28, 2025 at 10:30:16PM +0200, Andrey Albershteyn wrote:
> > > From: "Darrick J. Wong" <djwong@kernel.org>
> > >
> > > Create a function that will return selected information about the
> > > geometry of the merkle tree. Online fsck for XFS will need this piece
> > > to perform basic checks of the merkle tree.
> >
> > Just curious, why does xfs need this, but the existing file systems
> > don't? That would be some good background information for the commit
> > message.
>
> Hrmmm... the last time I sent this RFC, online fsck used it to check the
> validity of the merkle tree xattrs.
>
> I think you could also use it to locate the merkle tree at the highest
> possible offset in the data fork, though IIRC Andrey decided to pin it
> at 1<<53.

I also use it in a few places to get tree_size which used to adjust
the read size (xfs_fsverity_adjust_read and
iomap_fsverity_tree_end_align).

>
> (I think ext4 just opencodes the logic everywhere...)
>
> > > + if (!IS_VERITY(inode))
> > > + return -ENODATA;
> > > +
> > > + error = ensure_verity_info(inode);
> > > + if (error)
> > > + return error;
> > > +
> > > + vi = inode->i_verity_info;
> >
> > Wouldn't it be a better interface to return the verity_ino from
> > ensure_verity_info (NULL for !IS_VERITY, ERR_PTR for real error)
> > and then just look at the fields directly?
>
> They're private to fsverity_private.h.
>
> --D
>

--
- Andrey