Re: [PATCH v3 07/28] fsverity: always use bitmap to track verified status

Christoph Hellwig
2023-10-17T06:01:16Z

On Thu, Oct 12, 2023 at 08:12:09PM -0700, Darrick J. Wong wrote:
> I frankly have been asking myself why /this/ patchset adds so much extra
> code and flags and whatnot to XFS and fs/verity. From what I can tell,
> the xfs buffer cache has been extended to allocate double the memory so
> that xattr contents can be shadowed. getxattr for merkle tree contents
> then pins the buffer, shadows the contents, and hands both back to the
> caller (aka xfs_read_merkle_tree_block). The shadow memory is then
> handed to fs/verity to do its magic; following that, fsverity releases
> the reference and we can eventually drop the xfs_buf reference.
>
> But this seems way overcomplicated to me. ->read_merkle_tree_page hands
> us a pgoff_t and a suggestion for page readahead, and wants us to return
> an uptodate locked page, right?

It does. That beeing said I really much prefer the block based
interface from Andrey. It is a lot cleaner and without weird page
cache internals, although it can still be implemented very nicely
by file systems that store the tree in the page cache.

> The only thing I can't quite figure out is how to get memory reclaim to
> scan the extra address_space when it wants to try to reclaim pages.
> That part ext4 and f2fs got for free because they stuffed the merkle
> tree in the posteof space.

Except for th magic swapper_spaces, and address_space without an
inode is not a thing, so you need to allocate an extra inode anyway,
which is what reclaim works on.