Re: [PATCH 11/12] iomap: add read_folio_range() handler for buffered writes

Christoph Hellwig
2025-06-30T05:47:09Z

On Fri, Jun 27, 2025 at 03:18:36PM -0400, Brian Foster wrote:
> > +static int iomap_read_folio_range(const struct iomap_iter *iter,
> > + struct folio *folio, loff_t pos, size_t len)
> > {
> > + const struct iomap *srcmap = iomap_iter_srcmap(iter);
> > struct bio_vec bvec;
> > struct bio bio;
> >
> > - bio_init(&bio, iomap->bdev, &bvec, 1, REQ_OP_READ);
> > - bio.bi_iter.bi_sector = iomap_sector(iomap, block_start);
> > - bio_add_folio_nofail(&bio, folio, plen, poff);
> > + bio_init(&bio, srcmap->bdev, &bvec, 1, REQ_OP_READ);
> > + bio.bi_iter.bi_sector = iomap_sector(srcmap, pos);
> > + bio_add_folio_nofail(&bio, folio, len, offset_in_folio(folio, pos));
> > return submit_bio_wait(&bio);
> > }
>
> Hmm, so this kind of makes my brain hurt... pos here is now the old
> block_start and len is the old plen. We used to pass poff to the
> add_folio_nofail() call, and now that is dropped and instead we use
> offset_in_folio(..., pos). The old poff is an output of the previous
> iomap_adjust_read_range() call, which is initially set to
> offset_in_folio(folio, *pos), of which *pos is block_start and is bumped
> in that function in the same places that poff is. Therefore old poff and
> new offset_in_folio(folio, pos) are logically equivalent. Am I following
> that correctly?

You are, but given that you had to ask mean this should probably
be better documented ant/or be split into a separate patch.