Re: [PATCH v2 13/22] xfs: introduce XFS_FSVERITY_REGION_START constant

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

On Tue, Jan 13, 2026 at 01:23:06PM +0100, Andrey Albershteyn wrote:
> On 2026-01-12 14:46:31, Darrick J. Wong wrote:
> > On Mon, Jan 12, 2026 at 03:51:25PM +0100, Andrey Albershteyn wrote:
> > > This constant defines location of fsverity metadata in page cache of
> > > an inode.
> > > 
> > > Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>
> > > ---
> > >  fs/xfs/libxfs/xfs_fs.h | 22 ++++++++++++++++++++++
> > >  1 file changed, 22 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/fs/xfs/libxfs/xfs_fs.h b/fs/xfs/libxfs/xfs_fs.h
> > > index 12463ba766..b73458a7c2 100644
> > > --- a/fs/xfs/libxfs/xfs_fs.h
> > > +++ b/fs/xfs/libxfs/xfs_fs.h
> > > @@ -1106,4 +1106,26 @@
> > >  #define BBTOB(bbs)	((bbs) << BBSHIFT)
> > >  #endif
> > >  
> > > +/* Merkle tree location in page cache. We take memory region from the inode's
> > 
> > Dumb nit: new line after opening the multiline comment.
> > 
> > /*
> >  * Merkle tree location in page cache...
> > 
> > also, isn't (1U<<53) the location of the Merkle tree ondisk in addition
> > to its location in the page cache?
> 
> yes, it's file offset
> 
> > 
> > That occurs to me, what happens on 32-bit systems where the pagecache
> > can only address up to 16T of data?  Maybe we just don't allow fsverity
> > on 32-bit xfs.
> 
> hmm right, check in begin_enable() will be probably enough

I think that would probably be more of a mount-time prohibition?

Which would be worse -- any fsverity filesystem refuses to mount on
32-bit; or it mounts but none of the fsverity files are readable?

Alternately I guess for 32-bit you could cheat in ->iomap_begin
by loading the fsverity artifacts into the pagecache at 1<<39 instead of
1<<53, provided the file is smaller than 1<<39 bytes.  Writing the
fsverity metadata would perform the reverse translation.

(Or again we just don't allow mounting of fsverity on 32-bit kernels.)

--D

> > > + * address space for Merkle tree.
> > > + *
> > > + * At maximum of 8 levels with 128 hashes per block (32 bytes SHA-256) maximum
> > > + * tree size is ((128^8 − 1)/(128 − 1)) = 567*10^12 blocks. This should fit in 53
> > > + * bits address space.
> > > + *
> > > + * At this Merkle tree size we can cover 295EB large file. This is much larger
> > > + * than the currently supported file size.
> > > + *
> > > + * For sha512 the largest file we can cover ends at 1 << 50 offset, this is also
> > > + * good.
> > > + *
> > > + * The metadata is stored on disk as follows:
> > > + *
> > > + *	[merkle tree...][descriptor.............desc_size]
> > > + *	^ (1 << 53)     ^ (block border)                 ^ (end of the block)
> > > + *	                ^--------------------------------^
> > > + *	                Can be FS_VERITY_MAX_DESCRIPTOR_SIZE
> > > + */
> > > +#define XFS_FSVERITY_REGION_START (1ULL << 53)
> > 
> > Is this in fsblocks or in bytes?  I think the comment should state that
> > explicitly.
> 
> sure, will add it
> 
> -- 
> - Andrey
> 
>