From: Christoph Hellwig <hch@lst.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org
Subject: Re: bio_copy_from_iter
Date: Tue, 2 Jun 2026 08:03:19 +0200 [thread overview]
Message-ID: <20260602060319.GA325@lst.de> (raw)
In-Reply-To: <ah28-oyillEaOrm1@casper.infradead.org>
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.
next prev parent reply other threads:[~2026-06-02 6:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 17:10 bio_copy_from_iter Matthew Wilcox
2026-06-02 6:03 ` Christoph Hellwig [this message]
2026-06-03 4:05 ` bio_copy_from_iter Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260602060319.GA325@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.