On Tue, Dec 13, 2022 at 10:52:11PM -0800, Eric Biggers wrote:
> On Wed, Dec 14, 2022 at 08:10:10AM +1100, Dave Chinner wrote:
> > On Tue, Dec 13, 2022 at 11:33:54AM -0800, Eric Biggers wrote:
> > > On Tue, Dec 13, 2022 at 05:55:22PM +0000, Matthew Wilcox wrote:
> > > > I'm happy to work with you to add support for large folios to verity.
> > > > It hasn't been high priority for me, but I'm now working on folio support
> > > > for bufferhead filesystems and this would probably fit in.
> > >
> > > I'd be very interested to know what else is needed after commit 98dc08bae678
> > > ("fsverity: stop using PG_error to track error status") which is upstream now,
> > > and
> > > https://lore.kernel.org/linux-fsdevel/20221028224539.171818-1-ebiggers@xxxxxxxxxx/T/#u
> > > ("fsverity: support for non-4K pages") which is planned for 6.3.
> >
> > Did you change the bio interfaces to iterate a bvec full of
> > variable sized folios, or does it still expect a bio to only have
> > PAGE_SIZE pages attached to it?
> >
>
> You can take a look at fsverity_verify_bio() with
> https://lore.kernel.org/r/20221028224539.171818-2-ebiggers@xxxxxxxxxx applied.
> It uses bio_for_each_segment_all() to iterate through the bio's segments. For
> each segment, it verifies each data block in the segment, assuming bv_len and
> bv_offset are multiples of the Merkle tree block size. The file position of
> each data block is computed as '(page->index << PAGE_SHIFT) + bv_offset'.
Right, that still has the issue that it thinks each segment is a
struct page, whereas the iomap code is putting a struct folio that
contains a contiguous multipage folio into each segment.
> I suppose the issue is going to be that only the first page of a folio actually
> has an index. Using bio_for_each_folio_all() would avoid this problem, I think?
Yes, using bio_for_each_folio_all() is large folio aware. But then
you'll have to also pass the folio through the verification chain
for getting data offsets into the folio, etc.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
