Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp6163438rwl; Tue, 4 Apr 2023 08:39:44 -0700 (PDT) X-Google-Smtp-Source: AKy350bBtDe2b/O9CFO+JY46yU9XDYSbqwmRktkuQQYayzMGC9Tz3YA6Z1OuWGoKKS7G/enGu/Sc X-Received: by 2002:a17:903:2807:b0:1a0:485c:a6c with SMTP id kp7-20020a170903280700b001a0485c0a6cmr2831249plb.8.1680622784686; Tue, 04 Apr 2023 08:39:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680622784; cv=none; d=google.com; s=arc-20160816; b=JzMtCXEqPBgCweW/Wfcy2vBShfvUwQg5yopTYTYA6ANxROJpjq2Fy2PHXP8a0o2nmN DsUxsylsmP172InHORTbPUmu72+w8em9IUksqkPHGFlimizZNzRkcjovFSsh+0ftUbAm F9hha1dRmAbSB2HcTQradwAOsS5x+MOuwnxo+HS0+66tWyIfwkiLp7h4QEU7F//mKsr/ n8G+0pQtPQ6iR4pjaLvKiYzQhEOqoVhpy9wrzlMF+nqE1UdMMBDwzsRnHkOOOoiVhFEB UbdrSK0fiGpAYTQRwXLf1Dmdzdc8k8KSdMqNJNALE36IZFwdorJMZnz5w980qDJhwVjW g1Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=RdOI5GFBXvz2+CG+FGj78+ixvujqTitirHZIon4ASxI=; b=HRmHJryyBTg+I4t1z4I+7iOa/FPxB7l5e3miMtG4omN6J36a8XAtfKj8qC8pFBXVts s+GEpiI993uke35i6l5UAZARbuFjinOJRhHXMAPwO0SDbHRECYYtlFzvdAYg0qPJ5VH2 g/2pVNaVfcpm1nGP4yb3tH/fAN+FS/Xt/JTpeKWK+mzkPa8TZHy+HCzgrHSv/Gy3IrHD q0NKROpsLDzDximKwtM1KQ6WMrH8+ZaVVDsLVBwGzgF8HIQgdxcwF/Sp1yuaLjQEGqY3 7uOUzuzK0fNFkMUl41ezhanXk9kQh5dz+dusoeRavf88eHbfB+BMmAqUUn4bCFP3/yUw Zs0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=Ahkq88G6; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kk14-20020a170903070e00b0019f39d634basi10035316plb.262.2023.04.04.08.39.29; Tue, 04 Apr 2023 08:39:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=Ahkq88G6; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235731AbjDDPhq (ORCPT + 99 others); Tue, 4 Apr 2023 11:37:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235787AbjDDPhk (ORCPT ); Tue, 4 Apr 2023 11:37:40 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E86844ED1; Tue, 4 Apr 2023 08:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; 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; bh=RdOI5GFBXvz2+CG+FGj78+ixvujqTitirHZIon4ASxI=; b=Ahkq88G655jnqkQwTcWuEN6RRq h8yjZsKe+Ya6vZx2aj5qznyop6e9Fzt7P3UjXbJv3YvhdNnBewCyzgwcmFuLfVIeeo8HxJITi6zqF VoJUTlDJH5weysUFBompr1TeaFJM8Cz/IkuTB8joY0PeYjQN3d5QSaNxM/Z9JSHb6bQ7wMMntt34l 7HaqQ/BUxGKLrBBoO7LliRbNqk1tsSJOHBjuMuQ7qPPZJPANfHUxtfGJ6ugxXpXKnJP4ZjWXMUpqq uLWr5qtFE8Do8CSM76bQ0+Ns9i69roqtrrCuU0gAnh3o2vzYHSwZCxKjZFPcpTofIEqLTRS34odrA LrFUS5OQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1pjiiU-0021sG-0G; Tue, 04 Apr 2023 15:37:02 +0000 Date: Tue, 4 Apr 2023 08:37:02 -0700 From: Christoph Hellwig To: Andrey Albershteyn Cc: djwong@kernel.org, dchinner@redhat.com, ebiggers@kernel.org, hch@infradead.org, linux-xfs@vger.kernel.org, fsverity@lists.linux.dev, rpeterso@redhat.com, agruenba@redhat.com, xiang@kernel.org, chao@kernel.org, damien.lemoal@opensource.wdc.com, jth@kernel.org, linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com Subject: Re: [PATCH v2 09/23] iomap: allow filesystem to implement read path verification Message-ID: References: <20230404145319.2057051-1-aalbersh@redhat.com> <20230404145319.2057051-10-aalbersh@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230404145319.2057051-10-aalbersh@redhat.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org > if (iomap_block_needs_zeroing(iter, pos)) { > folio_zero_range(folio, poff, plen); > + if (iomap->flags & IOMAP_F_READ_VERITY) { Wju do we need the new flag vs just testing that folio_ops and folio_ops->verify_folio is non-NULL? > - ctx->bio = bio_alloc(iomap->bdev, bio_max_segs(nr_vecs), > - REQ_OP_READ, gfp); > + ctx->bio = bio_alloc_bioset(iomap->bdev, bio_max_segs(nr_vecs), > + REQ_OP_READ, GFP_NOFS, &iomap_read_ioend_bioset); All other callers don't really need the larger bioset, so I'd avoid the unconditional allocation here, but more on that later. > + ioend = container_of(ctx->bio, struct iomap_read_ioend, > + read_inline_bio); > + ioend->io_inode = iter->inode; > + if (ctx->ops && ctx->ops->prepare_ioend) > + ctx->ops->prepare_ioend(ioend); > + So what we're doing in writeback and direct I/O, is to: a) have a submit_bio hook b) allow the file system to then hook the bi_end_io caller c) (only in direct O/O for now) allow the file system to provide a bio_set to allocate from I wonder if that also makes sense and keep all the deferral in the file system. We'll need that for the btrfs iomap conversion anyway, and it seems more flexible. The ioend processing would then move into XFS. > @@ -156,6 +160,11 @@ struct iomap_folio_ops { > * locked by the iomap code. > */ > bool (*iomap_valid)(struct inode *inode, const struct iomap *iomap); > + > + /* > + * Verify folio when successfully read > + */ > + bool (*verify_folio)(struct folio *folio, loff_t pos, unsigned int len); Why isn't this in iomap_readpage_ops?