bio_copy_from_iter

bio_copy_from_iter

[Matthew Wilcox]

I'd like to remove copy_page_to_iter() (and only have
copy_folio_to_iter()).  That led me to looking at bio_copy_to_iter().
At first glance, switching it to bio_for_each_folio_all() makes a lot of
sense -- if there are large folios involved, then we can copy an entire
folio at a time instead of a page.

But what I can't prove to my satisfaction is that every bio passed to
bio_copy_to_iter() necessarily contains folios.  That's not currently
necessary, but will become necessary in the future. [1].

But I started thinking about what we could/should do in the future
when bvecs refer only to physical addresses and not pages.  What we'll
have is a list of (phys, len) tuples and need to copy that to an iter.
We don't have an API for that today.  Should we add:

copy_phys_to_iter(phys_addr_t phys, size_t len, struct iov_iter *i);

We arguably get even more benefit by doing this as we'd no longer break the
bio up into pages or folios, but can keep the contiguous chunks.  Not that
optimising bio_uncopy_user() is going to be a particularly big win,
but this API might be useful in places that are more performance sensitive.

[1] I believe all these bvecs are constructed using
blk_rq_map_user_iov() which can end up calling bio_add_vmalloc(),
and vmalloc pages will not be folios.

Re: bio_copy_from_iter

[Christoph Hellwig]

On Mon, Jun 01, 2026 at 06:10:18PM +0100, Matthew Wilcox wrote:
> I'd like to remove copy_page_to_iter() (and only have
> copy_folio_to_iter()).  That led me to looking at bio_copy_to_iter().
> At first glance, switching it to bio_for_each_folio_all() makes a lot of
> sense -- if there are large folios involved, then we can copy an entire
> folio at a time instead of a page.
> 
> But what I can't prove to my satisfaction is that every bio passed to
> bio_copy_to_iter() necessarily contains folios.  That's not currently
> necessary, but will become necessary in the future. [1].

bio_copy_to_iter is only called from blk_rq_unmap_user, which is only
used for bios created blk_rq_map_user_iov and only used when they had to
be bounce buffer.  There's two sources of pages for the bounce buffering:
The allocation in bio_copy_user_iov using alloca_page, and whatever sg
and st pass in through struct rq_map_data.  A good step to be able
to validate this would be to kill the mess around struct rq_map_data,
as in removing that structure.  There's no good reason why these
drivers should do their own allocations, this has mostly been
grandfathered in.

> [1] I believe all these bvecs are constructed using
> blk_rq_map_user_iov() which can end up calling bio_add_vmalloc(),
> and vmalloc pages will not be folios.

blk_rq_map_user_iov can't call bio_add_vmalloc.  And if you want to make
the vmalloc backing not folios you will be in a huge world of pain
anyway, as we expect to back folios using vmap/vm_map_ram and treating
vmalloc different from this will be extremely messy and invasive.