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

[Christoph Hellwig <hch@lst.de>]

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.