Re: [PATCH v3 03/35] fsverity: add consolidated pagecache offset for metadata

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

On Thu, Feb 19, 2026 at 02:09:54PM +0100, Andrey Albershteyn wrote:
> On 2026-02-18 13:57:32, Darrick J. Wong wrote:
> > On Wed, Feb 18, 2026 at 07:17:07AM +0100, Christoph Hellwig wrote:
> > > On Wed, Feb 18, 2026 at 12:19:03AM +0100, Andrey Albershteyn wrote:
> > > > Filesystems implementing fsverity store fsverity metadata on similar
> > > > offsets in pagecache. Prepare fsverity for consolidating this offset to
> > > > the first folio after EOF folio. The max folio size is used to guarantee
> > > > that mapped file will not expose fsverity metadata to userspace.
> > > > 
> > > > So far, only XFS uses this in futher patches.
> > > 
> > > This would need a kerneldoc comment explaining it.  And unless we can
> > > agree on a common offset and have the translation in all file systems,
> > > it probably makes sense to keep it in XFS for now.   If you have spare
> > > cycles doing this in common code would be nice, though.
> > 
> > fsverity_metadata_offset definitely ought to have a kerneldoc explaining
> > what it is (minimum safe offset for caching merkle data in the pagecache
> > if large folios are enabled).
> > 
> > and yes, it'd be nice to do trivial conversions, but ... I think the
> > only filesystem that has fscrypt and large folios is btrfs?  And I only
> > got that from dumb grepping; I don't know if it supports both at the
> > same time.
> > 
> > OTOH I think the ext4 conversion is trivial...
> > 
> > static struct page *ext4_read_merkle_tree_page(struct inode *inode,
> > 					       pgoff_t index,
> > 					       unsigned long num_ra_pages)
> > {
> > 	index += fsverity_metadata_offset(inode) >> PAGE_SHIFT;
> 
> I don't think it's that easy as ondisk file offset will be the same
> to this. So, this will require some offset conversion like in XFS
> and handling of old 64k offset.

Oh, right, because you still have to audit all the EXT4_PG_TO_LBLK
callsites to translate the fsverity region back to the ondisk offsets
before calling ext4_map_blocks().  You're right, this isn't a trivial
refactoring.  Comment withdrawn.

(I'd still like the kerneldoc tho)

--D

> -- 
> - Andrey
> 
>