From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFCB610F1; Sat, 24 Jan 2026 21:20:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769289604; cv=none; b=Vmml/LxuUCHmUS7mQQLiCJMiwKevvSc8EEtn4SGFa+cg/v0VVkWMsTSCn7LURpz/3LYm8l3FB9eUkhw1B0F6UGLIE7vPZ9OYmWd+c8UwB3+e1RgBPi17H2DhUgbs8OIEL5bDTHTC2ke43wYGDxsUHSgPDib9ok2DHiLy8WGXOg8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769289604; c=relaxed/simple; bh=oI+uA3O35prux956Vzu7Z1UUlwDa0yJcLaD0R2S8IsY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HBYDBN1cAHrUsw9qR1LS9tfdG32XF2WfaQUQV5TUe1EUlO3mKd4xhmlfKoGi5mxSVPuBAzW+L9X+zqEyjVerZvOGwhgQOfzy3Rbq+SGK4xkP4P8CBBJcDyMhsxxYSvI2MfVg9XrKCaNHn0FAvYHnBaxlDLlyo4rBMSJr5adXnjE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tx3PHjVF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tx3PHjVF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE05BC116D0; Sat, 24 Jan 2026 21:20:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769289604; bh=oI+uA3O35prux956Vzu7Z1UUlwDa0yJcLaD0R2S8IsY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tx3PHjVFa71TMA8P2jVrrQzZkrnzrpZqil3kd3DaCVTplbq9iK6DlJ8qsql1thPAv UNjuW1nfiRVWAbZf+LRjOeoUGh4XP+zmVrTNSc8g7amTOCb4vyFpcPWGiqIIenq2dB vft8MwRjbFKObQYd0ghcaHYdAZbM58IwoBylA9FvOa/jgLOmx9LjHJvNd36n4Pcm2R L8QHWrN4AT/1gM+82FP1MC53CTF2OW1OSsDNz1AatHjk7o4UTRUS+VrtUNfKt2GK58 xob/cAfD4zqAwb+w2F7IClIn40cu37XDMKbfm3FWH+cSbAYgtbkiZuLzAG63322rOw Mk5sbTrl4k/7w== Date: Sat, 24 Jan 2026 13:19:56 -0800 From: Eric Biggers To: Christoph Hellwig Cc: Al Viro , Christian Brauner , Jan Kara , David Sterba , Theodore Ts'o , Jaegeuk Kim , Chao Yu , Andrey Albershteyn , "Matthew Wilcox (Oracle)" , 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: [PATCH 06/11] fsverity: push out fsverity_info lookup Message-ID: <20260124211956.GF2762@quark> References: <20260122082214.452153-1-hch@lst.de> <20260122082214.452153-7-hch@lst.de> Precedence: bulk X-Mailing-List: fsverity@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260122082214.452153-7-hch@lst.de> On Thu, Jan 22, 2026 at 09:22:02AM +0100, Christoph Hellwig wrote: > Pass a struct fsverity_info to the verification and readahead helpers, > and push the lookup into the callers. Right now this is a very > dumb almost mechanic move that open codes a lot of fsverity_info_addr() > calls int the file systems. The subsequent patches will clean this up. > > This prepares for reducing the number of fsverity_info lookups, which > will allow to amortize them better when using a more expensive lookup > method. > > Signed-off-by: Christoph Hellwig > --- > fs/btrfs/extent_io.c | 4 +++- > fs/buffer.c | 4 +++- > fs/ext4/readpage.c | 11 ++++++++--- > fs/f2fs/compress.c | 4 +++- > fs/f2fs/data.c | 15 +++++++++++---- > fs/verity/verify.c | 26 ++++++++++++++------------ > include/linux/fsverity.h | 24 +++++++++++++++--------- > 7 files changed, 57 insertions(+), 31 deletions(-) This patch introduces another bisection hazard by adding calls to fsverity_info_addr() when CONFIG_FS_VERITY=n. fsverity_info_addr() has a definition only when CONFIG_FS_VERITY=y. Maybe temporarily add a CONFIG_FS_VERITY=n stub for fsverity_info_addr() that returns NULL, and also ensure that it's dereferenced only when it's known that fsverity verification is needed. Most of the call sites look okay, but the second one in ext4_mpage_readpages() needs to be fixed. > @@ -430,6 +431,7 @@ EXPORT_SYMBOL_GPL(fsverity_verify_blocks); > #ifdef CONFIG_BLOCK > /** > * fsverity_verify_bio() - verify a 'read' bio that has just completed > + * @vi: fsverity_info for the inode to be read > * @bio: the bio to verify > * > * Verify the bio's data against the file's Merkle tree. All bio data segments > @@ -442,13 +444,13 @@ EXPORT_SYMBOL_GPL(fsverity_verify_blocks); > * filesystems) must instead call fsverity_verify_page() directly on each page. > * All filesystems must also call fsverity_verify_page() on holes. > */ > -void fsverity_verify_bio(struct bio *bio) > +void fsverity_verify_bio(struct fsverity_info *vi, struct bio *bio) > { > struct inode *inode = bio_first_folio_all(bio)->mapping->host; > struct fsverity_verification_context ctx; > struct folio_iter fi; > > - fsverity_init_verification_context(&ctx, inode); > + fsverity_init_verification_context(&ctx, inode, vi); Note that fsverity_info has a back-pointer to the inode. So, fsverity_init_verification_context() could just take the vi and set ctx->inode to vi->inode. Then it wouldn't be necessary to get the inode from bio_first_folio_all(bio)->mapping->host (in fsverity_verify_bio()) or folio->mapping->host (in fsverity_verify_blocks()). Similarly in fsverity_readahead() too. (It might make sense to handle this part as a separate patch.) - Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BEBE1D715FC for ; Sat, 24 Jan 2026 21:20:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=iAz7NFN3qMIcbJ0oECssvHHmPlQuAaAeH1+/hLXbXL0=; b=lOJSiVQsDuHk4pjqAe8Ip5a1kO Qusbi7mzFh3s+habLrvqQJG/2MTbmicQgqSjv0oL7PvzlLRXUGMJCedvnOcjGmA1tvG5MdPypgIBy tgWJJsr4Z1w+I7Eo+opXXiuSVSrQwDGRaQIcyIfjdePGALR4ojkQfHYz5x7E1ADedMMc=; Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1vjl3F-0007NO-1S; Sat, 24 Jan 2026 21:20:13 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1vjl3D-0007NI-Sh for linux-f2fs-devel@lists.sourceforge.net; Sat, 24 Jan 2026 21:20:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=33od168mFhXauAgjQqwXth1skObIHMKdVKwrC1IyA80=; b=hlfl5qyXU4O3ozXywDgeAp4NDU 91VKxkKKotP30FRN8/edaupqSFVB5h5M9Hb9MTyBQd8Pw99UWUlWLZmoPEyZx2Wh2MZRpDfgFiBOP gVSRQGet41iiR/uVhVI8Qd2QOMxBxiPHUHooIrlwTcI/ric0PO0ezSGP1939EqdWDkwc=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=33od168mFhXauAgjQqwXth1skObIHMKdVKwrC1IyA80=; b=lBiCLIhey0X5QByB5zqubXF79R YLsExueWmlMtGUHYXbPnfmQSF8x2UwMmgLUS2OfoZVv8S4TJUHYuiOHBUOCJPeQfCRGayzfcC7jxb QRg51/Bp/l5HQ6c4YJLhBgQkaHtdYswY6Fsy1pJo4k+CJ54SH0FKHY7Rg9+K7vUcPqXk=; Received: from tor.source.kernel.org ([172.105.4.254]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1vjl3C-00086j-CT for linux-f2fs-devel@lists.sourceforge.net; Sat, 24 Jan 2026 21:20:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id B875960018; Sat, 24 Jan 2026 21:20:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE05BC116D0; Sat, 24 Jan 2026 21:20:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769289604; bh=oI+uA3O35prux956Vzu7Z1UUlwDa0yJcLaD0R2S8IsY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tx3PHjVFa71TMA8P2jVrrQzZkrnzrpZqil3kd3DaCVTplbq9iK6DlJ8qsql1thPAv UNjuW1nfiRVWAbZf+LRjOeoUGh4XP+zmVrTNSc8g7amTOCb4vyFpcPWGiqIIenq2dB vft8MwRjbFKObQYd0ghcaHYdAZbM58IwoBylA9FvOa/jgLOmx9LjHJvNd36n4Pcm2R L8QHWrN4AT/1gM+82FP1MC53CTF2OW1OSsDNz1AatHjk7o4UTRUS+VrtUNfKt2GK58 xob/cAfD4zqAwb+w2F7IClIn40cu37XDMKbfm3FWH+cSbAYgtbkiZuLzAG63322rOw Mk5sbTrl4k/7w== Date: Sat, 24 Jan 2026 13:19:56 -0800 To: Christoph Hellwig Message-ID: <20260124211956.GF2762@quark> References: <20260122082214.452153-1-hch@lst.de> <20260122082214.452153-7-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260122082214.452153-7-hch@lst.de> X-Headers-End: 1vjl3C-00086j-CT Subject: Re: [f2fs-dev] [PATCH 06/11] fsverity: push out fsverity_info lookup X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eric Biggers via Linux-f2fs-devel Reply-To: Eric Biggers Cc: fsverity@lists.linux.dev, Christian Brauner , Theodore Ts'o , Andrey Albershteyn , "Matthew Wilcox \(Oracle\)" , linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Al Viro , Jaegeuk Kim , David Sterba , Jan Kara , linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Thu, Jan 22, 2026 at 09:22:02AM +0100, Christoph Hellwig wrote: > Pass a struct fsverity_info to the verification and readahead helpers, > and push the lookup into the callers. Right now this is a very > dumb almost mechanic move that open codes a lot of fsverity_info_addr() > calls int the file systems. The subsequent patches will clean this up. > > This prepares for reducing the number of fsverity_info lookups, which > will allow to amortize them better when using a more expensive lookup > method. > > Signed-off-by: Christoph Hellwig > --- > fs/btrfs/extent_io.c | 4 +++- > fs/buffer.c | 4 +++- > fs/ext4/readpage.c | 11 ++++++++--- > fs/f2fs/compress.c | 4 +++- > fs/f2fs/data.c | 15 +++++++++++---- > fs/verity/verify.c | 26 ++++++++++++++------------ > include/linux/fsverity.h | 24 +++++++++++++++--------- > 7 files changed, 57 insertions(+), 31 deletions(-) This patch introduces another bisection hazard by adding calls to fsverity_info_addr() when CONFIG_FS_VERITY=n. fsverity_info_addr() has a definition only when CONFIG_FS_VERITY=y. Maybe temporarily add a CONFIG_FS_VERITY=n stub for fsverity_info_addr() that returns NULL, and also ensure that it's dereferenced only when it's known that fsverity verification is needed. Most of the call sites look okay, but the second one in ext4_mpage_readpages() needs to be fixed. > @@ -430,6 +431,7 @@ EXPORT_SYMBOL_GPL(fsverity_verify_blocks); > #ifdef CONFIG_BLOCK > /** > * fsverity_verify_bio() - verify a 'read' bio that has just completed > + * @vi: fsverity_info for the inode to be read > * @bio: the bio to verify > * > * Verify the bio's data against the file's Merkle tree. All bio data segments > @@ -442,13 +444,13 @@ EXPORT_SYMBOL_GPL(fsverity_verify_blocks); > * filesystems) must instead call fsverity_verify_page() directly on each page. > * All filesystems must also call fsverity_verify_page() on holes. > */ > -void fsverity_verify_bio(struct bio *bio) > +void fsverity_verify_bio(struct fsverity_info *vi, struct bio *bio) > { > struct inode *inode = bio_first_folio_all(bio)->mapping->host; > struct fsverity_verification_context ctx; > struct folio_iter fi; > > - fsverity_init_verification_context(&ctx, inode); > + fsverity_init_verification_context(&ctx, inode, vi); Note that fsverity_info has a back-pointer to the inode. So, fsverity_init_verification_context() could just take the vi and set ctx->inode to vi->inode. Then it wouldn't be necessary to get the inode from bio_first_folio_all(bio)->mapping->host (in fsverity_verify_bio()) or folio->mapping->host (in fsverity_verify_blocks()). Similarly in fsverity_readahead() too. (It might make sense to handle this part as a separate patch.) - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel