linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: fsverity@lists.linux.dev, linux-fsdevel@vger.kernel.org,
	linux-xfs@vger.kernel.org,
	Andrey Albershteyn <aalbersh@redhat.com>
Subject: Re: [PATCH] fsverity: support block-based Merkle tree caching
Date: Fri, 31 May 2024 21:52:28 +0000	[thread overview]
Message-ID: <20240531215228.GD2838215@google.com> (raw)
In-Reply-To: <20240531213212.GV52987@frogsfrogsfrogs>

On Fri, May 31, 2024 at 02:32:12PM -0700, Darrick J. Wong wrote:
> On Tue, May 14, 2024 at 06:53:20PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Currently fs/verity/ assumes that filesystems cache Merkle tree blocks
> > in the page cache.  Specifically, it requires that filesystems provide a
> > ->read_merkle_tree_page() method which returns a page of blocks.  It
> > also stores the "is the block verified" flag in PG_checked, or (if there
> > are multiple blocks per page) in a bitmap, with PG_checked used to
> > detect cache evictions instead.  This solution is specific to the page
> > cache, as a different cache would store the flag in a different way.
> > 
> > To allow XFS to use a custom Merkle tree block cache, this patch
> > refactors the Merkle tree caching interface to be based around the
> > concept of reading and dropping blocks (not pages), where the storage of
> > the "is the block verified" flag is up to the implementation.
> > 
> > The existing pagecache based solution, used by ext4, f2fs, and btrfs, is
> > reimplemented using this interface.
> > 
> > Co-developed-by: Andrey Albershteyn <aalbersh@redhat.com>
> > Signed-off-by: Andrey Albershteyn <aalbersh@redhat.com>
> > Co-developed-by: Darrick J. Wong <djwong@kernel.org>
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > ---
> > 
> > This reworks the block-based caching patch to clean up many different
> > things, including putting the pagecache based caching behind the same
> > interface as suggested by Christoph.
> 
> I gather this means that you ported btrfs/f2fs/ext4 to use the read/drop
> merkle_tree_block interfaces?

Yes, this patch does that.

> >                                       This applies to mainline commit
> > a5131c3fdf26.  It corresponds to the following patches in Darrick's v5.6
> > patchset:
> > 
> >     fsverity: convert verification to use byte instead of page offsets
> >     fsverity: support block-based Merkle tree caching
> >     fsverity: pass the merkle tree block level to fsverity_read_merkle_tree_block
> >     fsverity: pass the zero-hash value to the implementation
> > 
> > (I don't really understand the split between the first two, as I see
> > them as being logically part of the same change.  The new parameters
> > would make sense to split out though.)
> 
> I separated the first two to reduce the mental burden of rebasing these
> patches against new -rc1 kernels.  It's a lot less effort if one only
> has to concentrate on one aspect at a time.  You might have heard that
> it's difficult to add an xfs feature without it taking multiple kernel
> cycles.
> 
> (That said, 6.10 wasn't bad at all.)
> 

I'd be glad to start applying some of the fsverity patches for 6.11.  This one
seems good to me (if it's revised to split the new parameters back into separate
patches again), but it only really makes sense if XFS is going to use it, and
that seems uncertain now.  Either way though, we could go ahead with the
workqueue change, FS_XFLAG_VERITY, and tracepoints.

- Eric

      reply	other threads:[~2024-05-31 21:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-15  1:53 [PATCH] fsverity: support block-based Merkle tree caching Eric Biggers
2024-05-31 21:32 ` Darrick J. Wong
2024-05-31 21:52   ` Eric Biggers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240531215228.GD2838215@google.com \
    --to=ebiggers@kernel.org \
    --cc=aalbersh@redhat.com \
    --cc=djwong@kernel.org \
    --cc=fsverity@lists.linux.dev \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).