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.

Re: bio_copy_from_iter

[Matthew Wilcox]

On Tue, Jun 02, 2026 at 08:03:19AM +0200, Christoph Hellwig wrote:
> 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.

I must have misread the code.  I thought we could get to bio_map_kern()
from blk_rq_map_user_iov(), but on reviewing it now, I don't see a way.

> 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.

Yes, that doesn't look too bad.  Just sg and st using it.

> > [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.

Assuming you inadvertently transposed two words and meant to write "we
expect to back vmap/vm_map_ram using folios", I do intend to keep that
working, but I also do not intend to allocate folios in order to back
vmalloc areas.  I don't think it'll be all that messy, but I haven't
worked through the details of it yet.