Re: fsverity and large folios

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Apr 06, 2026 at 05:58:43AM +0100, Matthew Wilcox wrote:
> I suspect that fsverity simply doesn't support large folios today.

fs/verity/ already supports large folios in the mapping, including
verifying data from them and having the Merkle tree pages be backed by
them.  This is already being used on ext4.  It seems your concern is
about a more specific topic related to the Merkle tree caching.

> To make a move in that direction, I started to convert
> ->read_markle_tree_page() to ->read_merkle_tree_folio().  But there's
> a problem.  The Merkle tree is stored at "some offset" from the EOF.  And
> the knowledge of what offset is particular to the individual filesystem
> (or potentially each individual file).  That means that we can't hoist
> the "folio_file_page(folio, index)" call from the filesystem to the core
> code because the core code doesn't know what offset the tree is stored at.
> 
> And it's kind of dangerous because calling offset_in_folio(folio,
> byte_offset) doesn't work correctly eitheer (it's fine as long as the
> Merkle tree starts at some multiple of folio_size() from the base of
> the file ... which is a nasty gotcha to stumble across!)
> 
> This actually came up for me because fsverity is using PageChecked(),
> and it's the last part of the kernel still using PageChecked().  I was
> hoping to replace these uses with folio_test/set_checked(), but it all
> feels a bit fragile at this point.
> 
> I don't have an idea beyond exposing ->verity_metadata_pos() to the
> core code from individual filesystems, which feels like poor
> architecture.  Ideas welcome.

->read_merkle_tree_page() returns a page, but filesystems can back that
page with a large folio, as ext4 does.

While ext4 does it correctly as far as I can tell, btrfs does not, as
Christoph pointed out.  btrfs_read_merkle_tree_page() unconditionally
allocates an order-0 folio, even if the mapping uses folios of a
different order.  Yes, that needs to be fixed.

If I understand correctly, the other topic you're raising is whether the
page-granular use of PG_checked in fs/verity/verify.c can be replaced
with folio-granular use.

The bitmap-based code path (i.e. when fsverity_info::hash_block_verified
is allocated) partially addresses that.  But it still uses PG_checked to
determine whether the page was newly instantiated.

That use can be replaced with the folio-granular bit, tracking whether
the entire folio was newly instantiated.  But it will require a change
to the fsverity_operations, as you noticed.  There are multiple ways it
could be done, but I think one way would be:

    struct folio *(*read_merkle_tree_folio)(struct inode *inode, u64 pos,
                                            size_t *offset_in_folio_ret);

So it would take a byte position, which might not be folio-aligned or
even page-aligned.  It would return the folio containing it, along with
the byte offset of the requested position in that folio.

With that interface, fs/verity/ would have the information it needs to
determine which bitmap bits the folio-level checked bit correspond to.

Along with that, fsverity_init_merkle_tree_params() would need to enable
the bitmap-based code path whenever the file is using large folios.

- Eric