[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260123051216.GA24123@lst.de>
Date: Fri, 23 Jan 2026 06:12:16 +0100
From: Christoph Hellwig <hch@....de>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Christoph Hellwig <hch@....de>, t@...nolia.djwong.org,
Eric Biggers <ebiggers@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
David Sterba <dsterba@...e.com>, Theodore Ts'o <tytso@....edu>,
Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
Andrey Albershteyn <aalbersh@...hat.com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
fsverity@...ts.linux.dev
Subject: Re: [PATCH 04/11] fsverity: start consolidating pagecache code
On Thu, Jan 22, 2026 at 01:27:00PM -0800, Darrick J. Wong wrote:
> Nice hoist, though I wonder -- as an exported fs function, should we be
> checking that the returned folio doesn't cover EOF? Not that any of the
> users actually check that returned merkle tree folios fit that
> criterion.
As in past i_size because this is verity metadata? I think per the
last discussion that's only guranteed to be true, not the folio. It
might be useful to assert this, but it might be better for combine
this with the work to use different on-disk vs in-memory offset
and to consolidate all the offset magic. Which is worthwhile,
but І don't really want to add that in this series.
Powered by blists - more mailing lists