From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Biggers Date: Wed, 5 Apr 2023 18:02:47 +0000 Subject: [Cluster-devel] [PATCH v2 19/23] xfs: disable direct read path for fs-verity sealed files In-Reply-To: References: <20230404145319.2057051-1-aalbersh@redhat.com> <20230404145319.2057051-20-aalbersh@redhat.com> <20230404161047.GA109974@frogsfrogsfrogs> <20230405150142.3jmxzo5i27bbc4c4@aalbersh.remote.csb> <20230405150927.GD303486@frogsfrogsfrogs> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Apr 05, 2023 at 08:50:10AM -0700, Christoph Hellwig wrote: > On Wed, Apr 05, 2023 at 08:09:27AM -0700, Darrick J. Wong wrote: > > Thinking about this a little more -- I suppose we shouldn't just go > > breaking directio reads from a verity file if we can help it. Is there > > a way to ask fsverity to perform its validation against some arbitrary > > memory buffer that happens to be fs-block aligned? You could certainly add such a function that wraps around verify_data_block(). The minimal function prototype needed (without supporting readahead or reusing the ahash_request) would be something like the following, I think: bool fsverity_verify_blocks_dio(struct inode *inode, u64 pos, struct folio *folio, size_t len, size_t offset); And I really hope that you don't want to do DIO to the *Merkle tree*, as that would make the problem significantly harder. I think DIO for the data, but handling the Merkle tree in the usual way, would be okay? > > That would be my preference as well. But maybe Eric know a good reason > why this hasn't been done yet. > I believe it would be possible, especially if DIO to the Merkle tree is not in scope. There just hasn't been a reason to the work yet. And ext4 and f2fs already fall back to buffer I/O for other filesystem features, so there was precedent for not bothering with DIO, at least in the initial version. - Eric