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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
> > 
> > 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 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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux