public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Christoph Hellwig <hch@lst.de>, Jaegeuk Kim <jaegeuk@kernel.org>,
	Chao Yu <chao@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	David Sterba <dsterba@suse.com>, Theodore Ts'o <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>,
	Andrey Albershteyn <aalbersh@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, fsverity@lists.linux.dev
Subject: Re: fsverity speedup and memory usage optimization v5
Date: Mon, 2 Feb 2026 14:34:04 -0800	[thread overview]
Message-ID: <20260202223404.GA173552@quark> (raw)
In-Reply-To: <20260202211423.GB4838@quark>

On Mon, Feb 02, 2026 at 01:14:23PM -0800, Eric Biggers wrote:
> On Mon, Feb 02, 2026 at 07:06:29AM +0100, Christoph Hellwig wrote:
> > Hi all,
> > 
> > this series has a hodge podge of fsverity enhances that I looked into as
> > part of the review of the xfs fsverity support series.
> > 
> > The first part optimizes the fsverity read path by kicking off readahead
> > for the fsverity hashes from the data read submission context, which in my
> > simply testing showed huge benefits for sequential reads using dd.
> > I haven't been able to get fio to run on a preallocated fio file, but
> > I expect random read benefits would be significantly better than that
> > still.
> > 
> > The second part avoids the need for a pointer in every inode for fsverity
> > and instead uses a rhashtable lookup, which is done once per read_folio
> > or ->readahead invocation plus for btrfs only for each bio completion.
> > Right now this does not increse the number of inodes in
> > each slab, but for ext4 we are getting very close to that (within
> > 16 bytes by my count).
> > 
> > Changes since v5:
> >  - drop already merged patches
> >  - fix a bisection hazard for non-ENOENT error returns from
> >    generic_read_merkle_tree_page
> >  - don't recurse on invalidate_lock
> >  - refactor page_cache_ra_unbounded locking to support the above
> >  - refactor ext4 and f2fs fsverity readahead to remove the need for the
> >    first_folio branch in the main readpages loop
> 
> Applied to https://git.kernel.org/pub/scm/fs/fsverity/linux.git/log/?h=for-next
> 
> (Though it's getting late for v6.20 / v7.0.  So if there are any
> additional issues reported, I may have to drop it.)

Unfortunately this silently conflicts with changes in the f2fs tree.
Resolution doesn't look too bad, but we'll need to handle this.
Christoph, Jaegeuk, and Chao, let me know if this looks okay:

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index d9085d1236d97..081c441c59e71 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2449,11 +2449,13 @@ static void ffs_detach_free(struct folio *folio)
 	WARN_ON_ONCE(ffs->read_pages_pending != 0);
 	kmem_cache_free(ffs_entry_slab, ffs);
 }
 
 static int f2fs_read_data_large_folio(struct inode *inode,
-		struct readahead_control *rac, struct folio *folio)
+				      struct fsverity_info *vi,
+				      struct readahead_control *rac,
+				      struct folio *folio)
 {
 	struct bio *bio = NULL;
 	sector_t last_block_in_bio = 0;
 	struct f2fs_map_blocks map = {0, };
 	pgoff_t index, offset, next_pgofs = 0;
@@ -2519,13 +2521,12 @@ static int f2fs_read_data_large_folio(struct inode *inode,
 				ret = -EFSCORRUPTED;
 				goto err_out;
 			}
 		} else {
 			folio_zero_range(folio, offset << PAGE_SHIFT, PAGE_SIZE);
-			if (f2fs_need_verity(inode, index) &&
-			    !fsverity_verify_page(folio_file_page(folio,
-								index))) {
+			if (vi && !fsverity_verify_page(
+					  vi, folio_file_page(folio, index))) {
 				ret = -EIO;
 				goto err_out;
 			}
 			continue;
 		}
@@ -2552,14 +2553,14 @@ static int f2fs_read_data_large_folio(struct inode *inode,
 submit_and_realloc:
 			f2fs_submit_read_bio(F2FS_I_SB(inode), bio, DATA);
 			bio = NULL;
 		}
 		if (bio == NULL)
-			bio = f2fs_grab_read_bio(inode, block_nr,
-					max_nr_pages,
-					f2fs_ra_op_flags(rac),
-					index, false);
+			bio = f2fs_grab_read_bio(inode, vi, block_nr,
+						 max_nr_pages,
+						 f2fs_ra_op_flags(rac), index,
+						 false);
 
 		/*
 		 * If the page is under writeback, we need to wait for
 		 * its completion to see the correct decrypted data.
 		 */
@@ -2627,11 +2628,11 @@ static int f2fs_mpage_readpages(struct inode *inode, struct fsverity_info *vi,
 	struct address_space *mapping = rac ? rac->mapping : folio->mapping;
 	unsigned max_nr_pages = nr_pages;
 	int ret = 0;
 
 	if (mapping_large_folio_support(mapping))
-		return f2fs_read_data_large_folio(inode, rac, folio);
+		return f2fs_read_data_large_folio(inode, vi, rac, folio);
 
 #ifdef CONFIG_F2FS_FS_COMPRESSION
 	if (f2fs_compressed_file(inode)) {
 		index = rac ? readahead_index(rac) : folio->index;
 		max_nr_pages = round_up(index + nr_pages, cc.cluster_size) -

  reply	other threads:[~2026-02-02 22:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-02  6:06 fsverity speedup and memory usage optimization v5 Christoph Hellwig
2026-02-02  6:06 ` [PATCH 01/11] fsverity: don't issue readahead for non-ENOENT errors from __filemap_get_folio Christoph Hellwig
2026-02-02 13:23   ` Jan Kara
2026-02-17 21:14   ` [f2fs-dev] " patchwork-bot+f2fs
2026-02-02  6:06 ` [PATCH 02/11] readahead: push invalidate_lock out of page_cache_ra_unbounded Christoph Hellwig
2026-02-02 13:36   ` Jan Kara
2026-02-02 15:11   ` Matthew Wilcox
2026-02-02 15:17     ` Christoph Hellwig
2026-02-02 21:04       ` Eric Biggers
2026-02-02  6:06 ` [PATCH 03/11] ext4: move ->read_folio and ->readahead to readahead.c Christoph Hellwig
2026-02-02 13:32   ` Jan Kara
2026-02-03  0:57   ` Theodore Tso
2026-02-02  6:06 ` [PATCH 04/11] fsverity: kick off hash readahead at data I/O submission time Christoph Hellwig
2026-02-02  6:06 ` [PATCH 05/11] fsverity: deconstify the inode pointer in struct fsverity_info Christoph Hellwig
2026-02-02  6:06 ` [PATCH 06/11] fsverity: push out fsverity_info lookup Christoph Hellwig
2026-02-02  6:06 ` [PATCH 07/11] fs: consolidate fsverity_info lookup in buffer.c Christoph Hellwig
2026-02-02 13:38   ` Jan Kara
2026-02-02  6:06 ` [PATCH 08/11] ext4: consolidate fsverity_info lookup Christoph Hellwig
2026-02-02  6:06 ` [PATCH 09/11] f2fs: " Christoph Hellwig
2026-02-02  6:06 ` [PATCH 10/11] btrfs: " Christoph Hellwig
2026-02-02  6:06 ` [PATCH 11/11] fsverity: use a hashtable to find the fsverity_info Christoph Hellwig
2026-02-02 21:14 ` fsverity speedup and memory usage optimization v5 Eric Biggers
2026-02-02 22:34   ` Eric Biggers [this message]
2026-02-03  5:36     ` Christoph Hellwig
2026-02-04 14:54   ` Matthew Wilcox
2026-02-04 19:02     ` Eric Biggers
2026-02-04 19:09       ` Matthew Wilcox
2026-02-04 19:37         ` Eric Biggers

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=20260202223404.GA173552@quark \
    --to=ebiggers@kernel.org \
    --cc=aalbersh@redhat.com \
    --cc=brauner@kernel.org \
    --cc=chao@kernel.org \
    --cc=dsterba@suse.com \
    --cc=fsverity@lists.linux.dev \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jaegeuk@kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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